9.3 9.4 9.5 9.6 10 11 12 13
阿里云PostgreSQL 问题报告 纠错本页面

章 47. 复制进度跟踪

复制起源意在使在逻辑解码 之上更容易实现逻辑复制解决方案。它们提供了两个常见问题的解决方案:

复制起源只有两个属性,一个名称和一个OID。名称,这是应该用来指代跨系统的起源, 是自由形式的text。 它应该以使得由不同复制解决方案创建的复制起源之间的冲突不可能的方式使用; 例如,通过将复制解决方案的名称作为它的前缀。 OID仅用于避免在空间效率重要的情况下存储长版本。它不应该跨系统共享。

复制起源可以使用函数 pg_replication_origin_create() 创建;使用 pg_replication_origin_drop() 删除;在 pg_replication_origin 系统目录中查看。

构建复制解决方案的一个非常重要的部分是以安全的方式跟踪重放进度。 当应用过程或整个集群死机时,需要找出数据已成功复制的位置。 天真的解决方案,如更新每个重放事务的表中的行,有运行时开销和数据库膨胀等问题。

使用复制源基础结构,会话可以被标记为从远程节点重放(使用 pg_replication_origin_session_setup() 函数)。此外,每个源事务的LSN和提交时间戳可以使用 pg_replication_origin_xact_setup() 在每个事务基础上进行配置。如果这样做复制进度将以崩溃安全的方式持续。 可以在 pg_replication_origin_status 视图中看到所有复制原点的重放进度。单独起源的进展,例如, 当恢复复制时,可以使用pg_replication_origin_progress() 获取任何源或pg_replication_origin_session_progress() 获取在当前会话中配置的源。

在复制拓扑比从完全一个系统到另一个系统的复制更复杂, 另一个问题可能是难以避免再次复制重放的行。这可能导致复制和低效率的循环。 复制起点提供了一个可选的机制来识别和防止该循环。 当使用前一段中引用的函数进行配置时,传递给会话生成的输出插件回调 (参见第 46.6 节) 的每个更改和事务都使用生成会话的复制原点进行标记。 这允许在输出插件中对它们进行不同的处理。例如,忽略除本地原始行之外的所有行。 另外, filter_by_origin_cb回调可以用于基于源来过滤逻辑解码改变流。 虽然不太灵活,通过回调进行过滤比在输出插件中进行的过滤效率高得多。

<
/BODY >