PostgreSQL逻辑复制冲突时为什么应该优先以发布端数据为准

在PostgreSQL逻辑复制架构里，发布端（publisher）负责把表上的数据变更通过WAL日志解析成逻辑复制协议消息，订阅端（subscriber）再回放这些消息。当网络抖动、表结构不一致或人为在订阅端误改数据后，订阅端回放时会抛出冲突错误，例如duplicate key或missing row。面对这类冲突，一个容易忽视但关键的原则是：优先以发布端的数据为准进行处置，而不是用订阅端的现状去覆盖发布端。

逻辑复制冲突的主要类型

逻辑复制的冲突并不是随机发生的，通常可以归为几类。最常见的是主键或唯一索引冲突，即订阅端已经存在一条相同主键的记录，但发布端又发来了一条INSERT或UPDATE。这种情况多是因为有人在订阅端手动插入了数据，或者早期全量拷贝时遗漏了某些清洗步骤。

另一类是行不存在冲突。发布端发来一条UPDATE或DELETE，但订阅端找不到对应的行。这往往由于订阅端提前删除了数据，或是发布端和订阅端在初始同步阶段就没有对齐。还有一类是数据类型或约束冲突，比如发布端允许某字段为NULL，但订阅端建表时设成了NOT NULL，导致回放失败。

这些冲突如果处理不当，最容易出现的误操作就是直接在订阅端执行修正SQL，把订阅端的数据“补”成看起来合理的值，然后跳过错误。这种做法会让订阅端逐渐偏离发布端的真实状态，后期排查极为困难。

为什么必须优先以发布端为准

发布端是业务系统的唯一写入入口，所有变更都经过应用层的事务控制、业务校验以及数据库层的约束检查。也就是说，发布端提交的数据在业务逻辑上已经被认定为“正确结果”。订阅端本质上只是一个异步的只读镜像，它不应该拥有比发布端更高的数据权威。

如果以订阅端优先，就等于承认订阅端上可能未经业务校验的数据可以推翻发布端的结论。举个例子，电商系统的订单状态在发布端已经是“已支付”，但订阅端由于手工改库变成了“待支付”，若按订阅端覆盖，财务对账就会出现缺口。以发布端优先则只需把订阅端重新对齐到发布端，业务含义始终清晰。

此外，逻辑复制的设计目标本身就是最终一致性，而不是多主写入。PostgreSQL官方逻辑复制并不支持双向冲突合并，因此任何“哪边新就听哪边”的想法都会破坏复制协议的假设。明确发布端优先，能统一团队排障时的决策路径，减少扯皮。

冲突解决的具体实践方法

当冲突导致逻辑复制Worker报错停止时，首先应通过订阅端日志定位出错的事务。常用的做法是查询pg_stat_subscription视图，结合订阅端日志中的ERRCODE判断冲突类型。确认是订阅端脏数据引起后，优先选择在订阅端删除或修正那行“多余”的记录，让发布端的变更能够正常回放。

如果冲突事务已经无法通过简单删行解决，可以使用ALTER SUBSCRIPTION跳过特定LSN。下面示例展示如何暂停订阅并跳过出错位置：

-- 查看订阅状态，确认冲突的远程LSN
SELECT subname, received_lsn, latest_end_lsn
FROM pg_stat_subscription;

-- 暂停订阅，避免持续报错
ALTER SUBSCRIPTION my_sub DISABLE;

-- 跳过导致冲突的事务（将下方LSN替换为实际值）
SELECT pg_replication_origin_advance('pgorigin_my_sub', '0/1A2B3C4D');

-- 重新启用订阅
ALTER SUBSCRIPTION my_sub ENABLE;

上述方式仅跳过单个事务，适用于偶发冲突。但如果订阅端已经被误操作污染较多，更稳妥的方案是对冲突表做重新同步。可先在订阅端删除该表订阅关系，再使用COPY或pg_dump从发布端重新拉取基线数据。

-- 在订阅端移除某张表的订阅
ALTER SUBSCRIPTION my_sub DROP TABLE orders;

-- 在订阅端清空本地错误数据
TRUNCATE TABLE orders;

-- 在发布端确保表仍在发布列表中
ALTER PUBLICATION my_pub ADD TABLE orders;

-- 在订阅端重新添加表，触发全量拷贝
ALTER SUBSCRIPTION my_sub ADD TABLE orders;

重新同步虽然会短时间占用网络与IO，但能彻底消除订阅端长期偏离发布端带来的隐患。无论采用哪种方式，核心原则不变：让订阅端去适应发布端，而不是反过来。

预防冲突的运维建议

除了事后解决，更重要的是预防。首要规则是严格禁止在订阅端对任何逻辑复制表执行写操作。可以通过在订阅端将这些表设为只读角色，或利用触发器阻止INSERT、UPDATE、DELETE来兜底。

其次，保持发布端与订阅端表结构同源。任何DDL变更都应先在发布端执行，并确认逻辑复制能正常传输，再于订阅端应用相同DDL。可以使用工具比对两端information_schema，及时发现字段差异。最后，监控pg_stat_subscription的lag与错误状态，把冲突暴露在业务发现之前。

当团队形成“发布端即事实来源”的共识，配合自动化跳过重试与告警，逻辑复制的运维成本会明显下降，也能保障下游报表、缓存同步等系统拿到可信数据。

PostgreSQL逻辑复制冲突解决修改时间：2026-08-12 01:15:28