PostgreSQL 16 级联逻辑复制与 origin 详解：多层拓扑下的事务顺序保障

你好，我是你们的数据库老朋友，这次咱们来聊聊 PostgreSQL 16 在逻辑复制，特别是级联逻辑复制方面的 origin 选项，以及它如何帮助我们构建复杂的多层复制拓扑，并确保事务顺序的正确传递。

为什么需要级联逻辑复制？

在很多场景下，单层的发布/订阅模型可能无法满足我们的需求。例如：

• 数据汇总： 我们可能需要将多个区域的数据中心的数据复制到一个中心数据库进行汇总分析。
• 读写分离+异地灾备： 我们可能需要在本地搭建一个读写分离集群，同时在异地搭建一个灾备中心。
• 多级数据分发： 我们可能需要将数据从总部逐级分发到各个分公司、门店。

这些场景都需要用到级联逻辑复制，也就是让订阅服务器同时成为发布服务器，将数据进一步复制到下游。

PostgreSQL 逻辑复制基础

在深入讨论 origin 之前，我们先简单回顾一下 PostgreSQL 逻辑复制的基础知识。

PostgreSQL 的逻辑复制基于发布/订阅模型。发布服务器（Publisher）上的发布（Publication）定义了要复制的数据变更集合（通常是一个或多个表）。订阅服务器（Subscriber）上的订阅（Subscription）连接到发布服务器，并接收发布定义的数据变更。

逻辑复制的核心是 WAL（Write-Ahead Log）日志。发布服务器将 WAL 日志解码成逻辑变更流，然后发送给订阅服务器。订阅服务器接收到这些变更后，在本地重放，从而实现数据的复制。

级联逻辑复制中的挑战：事务顺序

在级联复制中，一个订阅服务器同时也是发布服务器，它会将从上游接收到的数据变更再次发布给下游的订阅服务器。这时，一个关键的挑战出现了：如何确保事务的顺序在整个复制链中保持一致？

想象一下，如果事务 A 在原始发布服务器上先于事务 B 执行，但在中间的某个订阅/发布服务器上，由于某种原因，事务 B 先于事务 A 被应用，然后又被发布到下游，这就会导致数据不一致。

PostgreSQL 16 的 origin 选项

为了解决这个问题，PostgreSQL 引入了 origin 选项。origin 选项可以在创建发布时指定，它控制了哪些事务会被发布到下游。

origin 有两个可选值：

• none (默认值): 只发布本地事务，不发布从其他 origin 接收到的事务。
• any: 发布所有事务，包括本地事务和从其他 origin 接收到的事务。

在级联复制中，中间的订阅/发布服务器通常应该将 origin 设置为 any，这样才能将从上游接收到的事务继续发布到下游。

详细配置示例

假设我们有这样一个复制拓扑：Server A (主库) -> Server B (级联节点) -> Server C (最终订阅者)

1. 在 Server A 上创建发布 (Publication)

CREATE PUBLICATION pub_a FOR TABLE mytable;

这里我们假设要复制的表名为 mytable。注意，origin 默认为 none，只发布本地事务。

2. 在 Server B 上创建订阅 (Subscription)

CREATE SUBSCRIPTION sub_a CONNECTION 'host=server_a ...' PUBLICATION pub_a;

3. 在 Server B 上创建发布 (Publication)

CREATE PUBLICATION pub_b FOR TABLE mytable WITH (publish = 'insert, update, delete, truncate', origin = 'any');

这里是关键！我们必须将 origin 设置为 any，这样 Server B 才会将从 Server A 接收到的事务发布给 Server C。

4. 在 Server C 上创建订阅 (Subscription)

CREATE SUBSCRIPTION sub_b CONNECTION 'host=server_b ...' PUBLICATION pub_b;

通过这样的配置，Server A 上的事务会先复制到 Server B，然后由 Server B 再次发布到 Server C，事务的顺序在整个过程中得以保持。

故障排除技巧

级联复制的配置相对复杂，出现问题时排查起来也比较困难。下面是一些常见的故障排除技巧：

1. 检查复制状态：

   在每个节点上，使用 pg_stat_replication 和 pg_stat_subscription 视图检查复制状态。

   SELECT * FROM pg_stat_replication;  -- 查看发布服务器的复制状态
   SELECT * FROM pg_stat_subscription; -- 查看订阅服务器的复制状态

2. 检查 WAL 日志：

   如果复制延迟较大，可以检查 WAL 日志的生成和接收情况。

   -- 在发布服务器上
   SELECT slot_name, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;
    
   -- 在订阅服务器上
   SELECT slot_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_replication_slots;

3. 检查错误日志：

   PostgreSQL 的错误日志通常会包含有关复制问题的详细信息。

4. 检查 origin 设置：

   确保中间节点的发布配置了 origin = 'any'。

5. 网络连通性：

   确保所有节点之间的网络连接正常。

6. 监控复制延迟

长期监控复制延迟，当复制延迟超过预定阀值时，告警。

常见问题与解答 (FAQ)

Q: 如果中间节点没有设置 origin = 'any'，会发生什么？

A: 中间节点只会发布本地事务，从上游接收到的事务不会被发布到下游，导致下游数据不完整。

Q: origin = 'none' 有什么用？

A: origin = 'none' 主要用于非级联复制的场景，或者用于某些特殊的级联复制场景，例如只希望将本地的某些变更发布到下游，而不发布从上游接收到的所有变更。

Q: 除了 insert, update, delete, truncate，publish 选项还有其他值吗？

A: 从PostgreSQL 15开始，还支持'all tables' 选项, 可以将发布服务器上的所有表的变化发布到订阅者.

Q: 我可以在一个发布中包含多个表吗？

A: 可以，使用逗号分隔多个表名即可。例如：CREATE PUBLICATION pub_all FOR TABLE table1, table2, table3;

Q：我可以在创建PUBLICATION后添加或者删除表吗？

A：可以，使用ALTER PUBLICATION命令。例如：ALTER PUBLICATION pub_all ADD TABLE table4; 或 ALTER PUBLICATION pub_all DROP TABLE table1;

总结

PostgreSQL 16 的 origin 选项为我们提供了构建复杂级联逻辑复制拓扑的能力，并确保了事务顺序在整个复制链中的正确传递。理解并正确配置 origin 选项，对于构建高可用、可扩展的数据库架构至关重要。希望这篇文章能帮助你更好地理解和使用 PostgreSQL 的逻辑复制功能。如果你有任何问题或者想进一步讨论，欢迎留言！