在同一套PostgreSQL集群或者跨地域的两套数据库之间，双向逻辑复制允许两边的节点同时接受写入，并通过逻辑解码将变更同步到对端。这种架构在某些需要本地写入延迟极低、又要求最终一致性的场景中非常有用。但PostgreSQL的逻辑复制最初是按照单向主从设计的，想要把它改造成双向多主，必须在应用层面和数据库配置层面做出一系列的调整，否则冲突和循环会让系统迅速失控。
双向复制的核心冲突与解决思路
双向复制的本质是在两个节点上都创建发布（PUBLICATION），并且相互订阅（SUBSCRIPTION）对方的发布。假设节点A上有表t1，节点B上也有结构相同的表t1，当一条INSERT同时在两边发生时，逻辑复制会将A的插入发送到B，也会将B的插入发送到A。如果两个插入使用相同的主键值，就会产生主键冲突，导致复制出错停止。即使主键不重复，所有变更都会被来回传递，如果没有循环抑制机制，变更会在两个节点之间无限传播。
解决行级冲突通常有两种思路：一是让应用层保证写入不会冲突，例如对不同的节点分配不同的主键范围；二是让数据库具备冲突检测和覆盖能力。PostgreSQL从版本15开始提供了内置的冲突解决参数，但更早的版本只能通过调整订阅端的行为来临时绕过错误，比如忽略冲突或者当作UPDATE处理。对于生产环境来说，推荐使用规划好的主键生成策略，例如使用UUID、或者将主键设计为“节点标识+本地序列”的复合结构，这样即使两边同时插入，也永远不会产生相同的键值。
当确实需要处理冲突时，可以在订阅端使用 CREATE SUBSCRIPTION ... WITH (origin = none) 配合 ALTER SUBSCRIPTION ... SET (disable_on_error = false) 等选项，再结合逻辑复制中的冲突解决函数 pg_replication_origin_advance 来重新定位复制位点，但这些操作都比较繁琐。高版本PostgreSQL提供的订阅参数 conflict_resolution 可以直接指定冲突行为，如 update_exists、skip 或 last_update_wins。下面是一个设置订阅并指定冲突解决为“保留最新更新”的示例：
-- 在节点B上创建订阅，指定当出现冲突时采用last_update_wins策略
CREATE SUBSCRIPTION sub_from_a
CONNECTION 'host=node_a dbname=mydb'
PUBLICATION pub_on_a
WITH (copy_data = false,
conflict_resolution = last_update_wins,
origin = none);
即使这样，也请不要盲目依赖冲突解决参数，因为不是所有类型的冲突都能被自动处理，且“覆盖”操作可能导致意料之外的数据丢失。更好的做法是从源头上避免冲突。
序列、自增列与标识列的陷阱
很多表的主键是通过序列（SERIAL、BIGSERIAL）或者标识列（GENERATED ALWAYS AS IDENTITY）自动生成的。在两个节点同时写入时，各自的序列会从相同的起点开始递增，很容易分配出相同的数值，从而导致主键冲突。这类问题在初始化双向复制时尤其突出，因为两边的表结构往往是完全一致的，序列的当前值也是相同的。
解决办法是调整每个节点的序列，使它们生成不重叠的值范围。如果只有两个节点，可以将节点A的序列步长设置为偶数，节点B的序列步长设置为奇数，并错开起始值。使用 ALTER SEQUENCE 配合 INCREMENT BY 2 和 START WITH 来实现：
-- 节点A：序列生成偶数 ALTER SEQUENCE mytable_id_seq INCREMENT BY 2 START WITH 2; -- 节点B：序列生成奇数 ALTER SEQUENCE mytable_id_seq INCREMENT BY 2 START WITH 1;
对于标识列，也可以使用类似的思想，但在定义表时就要指定序列生成器。如果是已经存在的表，可以修改标识列的序列属性。需要注意的是，逻辑复制只会同步DML操作（INSERT/UPDATE/DELETE），不会自动同步序列的当前值。因此，两边序列的起始值调整必须在复制开始前完成，并且要保证在复制启动后序列不会被其他无关连接重置。如果后续需要增加第三个节点，可以将步长改为3并根据节点编号分配不同的偏移量，始终保持范围分离。
另一种更彻底的做法是使用UUID作为主键，这样完全避免了数值范围分配的问题。但UUID作为主键会带来存储体积增大和索引效率下降等问题，需要在设计时权衡。如果业务允许，采用“节点ID+本地自增”的复合主键也是一种可行的方案，但这会改变表结构和关联查询的方式，成本较高。
DDL变更的同步与复制循环的阻断
逻辑复制不会自动复制DDL语句。如果你在节点A上执行了 ALTER TABLE ADD COLUMN，节点B上的表结构并不会自动改变。当节点B试图应用来自节点A的、包含新列的DML变更时，会因为列不存在而报错。因此，在双向复制环境中进行DDL变更，必须有一种同步机制，确保两个节点的表结构保持一致。
常见的做法有两种：一是使用外部工具比如pg_dump/pg_restore或者专门的迁移工具，配合锁定写入窗口来同步执行DDL；二是在每个节点上都手动执行相同的DDL，并保证执行顺序一致。PostgreSQL 16开始引入了对DDL逻辑复制的初始支持，但仍处于发展阶段，不能完全依赖。在实际操作中，建议将DDL变更纳入变更管理流程，先在测试环境验证两边的兼容性，再按计划在生产节点上串行执行。很多团队会写一个简单的脚本，通过 pg_logical_slot_get_changes 检查复制延迟，确认没有正在传播的DML后，再分别执行DDL，最大限度地降低不一致风险。
另一个关键点是防止复制回环。默认情况下，逻辑复制不会给被同步的表增加任何标记，因此一个变更可能会从A复制到B，又从B复制回A，形成无限循环。通过设置订阅参数的 origin = none，可以告诉订阅端忽略来自另一个复制源的起源标识，但这样并不彻底。更可靠的方法是在发布端利用表级的复制标识，结合每行数据的来源信息进行过滤。例如，在每张需要双向复制的表中增加一个 source_node 字段，并在应用程序写入时带入当前节点信息。这样，在定义发布时通过行筛选（PUBLICATION ... FOR TABLE ... WHERE (source_node IS DISTINCT FROM current_node)）机制就可以只复制来自对端的数据，从根本上切断循环。下面是定义带行筛选的发布的示例：
-- 假设表中存在source_id字段，1代表节点A，2代表节点B
-- 在节点A上创建发布，只发布source_id不等于1的行（即来自B的数据）
CREATE PUBLICATION pub_a_bidi FOR TABLE orders
WHERE (source_id IS DISTINCT FROM 1);
-- 在节点B上创建发布，只发布source_id不等于2的行
CREATE PUBLICATION pub_b_bidi FOR TABLE orders
WHERE (source_id IS DISTINCT FROM 2);
这种方式需要在应用层或者触发器层面维护 source_id 的值，虽然增加了开发量，但能从源头上杜绝循环，并且可以灵活扩展至多个节点。如果不想改动表结构，也可以利用PostgreSQL扩展插件如pglogical提供的额外功能，不过那会引入对扩展的依赖。从长期维护的角度来看，表结构中加入来源标记是成本最低、最可控的方案。
监控、故障恢复与性能考量
双向逻辑复制的复杂性使得监控变得尤为重要。必须持续跟踪复制槽的状态、复制延迟、冲突发生次数以及各个复制进程的健康情况。可以通过查询系统视图 pg_stat_replication、pg_replication_slots 以及 pg_stat_subscription 来获取关键指标。当订阅端因为冲突或错误停止时，订阅状态会变为 disabled 或者一直处于重试状态，必须在第一时间感知并介入。建议设置告警监控订阅的 last_error_time 和 last_error_message，以便快速定位问题。
性能方面，双向复制实质上让每个写入操作都产生了至少两次逻辑解码和网络传输的开销。在高并发写入场景下，逻辑解码的CPU消耗和复制槽磁盘占用不容小觑。你可能会观察到WAL保留量上升，因为复制槽会阻止WAL被清理。务必为每个复制槽设置合理的 max_slot_wal_keep_size 参数，并在节点长期断开时评估是否需要丢弃复制槽，以防止磁盘空间耗尽。此外，对于热点表，建议开启逻辑复制的并行应用功能（通过 streaming = parallel 参数），这将显著提高应用端处理变更的速度，降低复制延迟。
在故障恢复方面，双向复制架构下一个节点宕机后，通常可以由另一个节点继续提供服务。当故障节点恢复后，逻辑复制会自动从上次已确认的LSN位置接续，但如果故障期间对端发起了DDL，可能会造成结构不一致而无法应用。因此，应急预案中应当包含对恢复节点的数据核对步骤，甚至采用重新全量复制的方式保证数据完全一致。总之，双向逻辑复制在带来灵活性的同时，也显著提升了运维的复杂度，上线前务必进行充分的压力测试和混沌工程验证，确保团队对这套架构的运作机制有透彻的理解。
PostgreSQL逻辑复制双向复制修改时间：2026-08-12 18:25:06