2025年9月25日: PostgreSQL 18 发布!
支持的版本: 当前 (18) / 17 / 16 / 15 / 14 / 13
开发版本: devel
不支持的版本: 12 / 11 / 10 / 9.6 / 9.5

第 48 章。下层复制进度跟踪

复制源旨在使基于逻辑解码实现逻辑复制解决方案更加容易。它们解决了两个常见的问题:

  • 如何安全地跟踪复制进度

  • 如何根据行的来源更改复制行为;例如,以防止双向复制设置中的循环。

复制源只有两个属性:名称和 ID。名称(用于跨系统引用源)是自由形式的 text。它应该以一种不大可能与不同复制解决方案创建的复制源发生冲突的方式使用;例如,在其前面加上复制解决方案的名称。ID 仅用于在空间效率很重要的情况下避免存储长名称。它绝不应在系统之间共享。

可以使用函数 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()(用于当前会话中配置的源)来获取单个源的进度,例如在恢复复制时。

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

提交更正

如果您在文档中发现任何不正确的内容、与您对特定功能的体验不符或需要进一步澄清的内容,请使用此表单报告文档问题。