PostgreSQL 逻辑复制的订阅端虽然能够持续接收表数据变化，但序列（sequence）并不会跟随发布端的 nextval 调用自动更新。这是因为逻辑复制的复制对象是表，序列的当前值属于数据库对象的元数据状态，不会产生可供订阅端消费的变更事件。很多业务在切换到逻辑复制后，第一次向订阅端插入数据就出现 duplicate key value violates unique constraint，根因几乎都是序列值没有校准。要解决这个问题，需要先理解逻辑复制和序列状态的差异，再结合 setval 与运维脚本完成同步。
一、逻辑复制为何不能同步序列
PostgreSQL 的逻辑复制基于发布（PUBLICATION）和订阅（SUBSCRIPTION）机制。发布端通过逻辑解码将指定表上的 DML 事务转换为变更数据，订阅端再将这些变更应用到本地表。创建发布时通常使用 CREATE PUBLICATION pub FOR TABLE orders 或 FOR ALL TABLES，这里的对象范围只包括表，并不包含序列。即便某个表的主键默认值来自序列，例如 id bigserial primary key，发布端在 INSERT 时生成的 id 会作为普通列值被同步到订阅端，但序列自身的 last_value 不会被同步。
序列在 PostgreSQL 中不是表，它的状态记录在 pg_sequence 系统目录中，调用 nextval 会使状态变化，这种变化虽然写入 WAL 以支持崩溃恢复，但逻辑解码插件不会把系统目录的变更作为可发布的 DML 事件。订阅端初始同步时，如果使用的是逻辑复制的初始表同步，会在本地重建表结构和序列定义，但序列的起始值可能仍是定义时的值，而不是发布端当前的 last_value。结果就是表里已经有大量数据，序列却停留在很靠前的位置。
这与物理复制形成明显区别。物理复制直接传输 WAL 并在字节级别恢复数据页，序列状态作为共享内存和系统目录的一部分会被同步到备库，因此备库序列值通常与主库一致。逻辑复制则只重放表数据，序列属于需要在应用层或运维层补偿的对象。理解这一点可以避免在架构选型时对逻辑复制产生不切实际的期望。
二、检查序列差异并执行一次性修复
当订阅端出现主键冲突时，第一步不是立刻手动插入一条更大的 id，而是系统性地检查所有序列当前值。发布端执行以下查询可以列出业务 schema 中每个序列的 last_value：
SELECT schemaname, sequencename, last_value
FROM pg_sequences
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY schemaname, sequencename;
pg_sequences 视图能够直接反映序列最近一次由 nextval 分配的缓存结束位置。需要注意的是，last_value 不是下一次将要返回的值，当 setval 的第三个参数为 true 时，下一次 nextval 会返回 last_value + 1。因此在校准订阅端序列时，应该传入发布端当前 last_value，并根据业务需要决定是否预留缓存间隔。
可以在发布端用一条 SQL 生成完整的 setval 校准语句，再复制到订阅端执行。下面查询会生成包含 schema、序列名和当前值的命令：
SELECT 'SELECT setval(' || quote_literal(quote_ident(schemaname) || '.' || quote_ident(sequencename)) || ', ' || last_value || ', true);'
FROM pg_sequences
WHERE schemaname NOT IN ('pg_catalog', 'information_schema');
将生成结果拿到订阅端执行，例如：
SELECT setval('public.orders_id_seq', 10520, true);
执行完成后，可以通过简单插入测试验证是否还冲突。对于数据量较大的环境，建议在业务低峰期执行，并放在事务中，因为 setval 本身是立即生效且不会阻塞其他会话。
三、将序列校准纳入切换流程与自动化
逻辑复制场景中序列同步不应该等到出现故障后再处理，而应作为标准切换步骤。常见的做法是先停止应用写入或切换流量，再在发布端查询序列当前值，通过脚本在订阅端执行 setval。如果使用 pg_dump，可以只导出序列对象及其当前值。命令如下：
pg_dump -h pg-publisher -U postgres -d appdb --data-only --table=public.orders_id_seq > /tmp/seq_sync.sql psql -h pg-subscriber -U postgres -d appdb -f /tmp/seq_sync.sql
上面命令中的 --table 参数直接指定序列名时，pg_dump 会导出对应的 CREATE SEQUENCE 和 setval 调用，这样可以保证订阅端序列定义与发布端一致。但需要注意，如果只导出序列，执行后订阅端序列的当前值可能略高于实际数据最大值，因为发布端可能缓存了一些未使用的序列值。对于普通业务来说，这部分空洞通常可以接受；如果严格要求连续分配，则不适合使用序列缓存。
另一种思路是在订阅端应用代码中避免依赖本地序列自动生成主键。例如切换演练时暂时禁止应用直接向订阅端写入，或者将所有写入集中到发布端，订阅端只作为只读副本。对于需要双向写入或读写的场景，建议使用 UUID 主键、应用层分布式 ID 生成器，或者给每个节点分配不同的序列步长范围，从设计上规避序列冲突。
还可以将序列同步脚本加入高可用平台的切换钩子。比如在 Patroni、repmgr 或自研切换工具中，在主备角色切换成功后从新主库获取序列值，并在旧主库或新备库上执行校准。这样每次切换后都能自动对齐序列，减少人工干预。监控方面，可以定期比较两端序列 last_value，当差距超过阈值时发出告警。
四、常见误区和排查方法
一个常见误区是使用 ALTER SEQUENCE RESTART 来修复序列。RESTART 会先把序列重置到指定值，下一次 nextval 返回该值，而不是从 last_value + 1 开始。如果误用 RESTART 并传入发布端 last_value，可能会导致下一次插入生成的 id 与已有数据冲突，因为 nextval 会返回这个值本身。相比之下，setval 第三个参数 true 才表示下一次 nextval 返回 last_value + 1。
另一个常见问题是只重置了显式关联的序列，遗漏了其他序列对象。很多表不一定通过 serial 或 identity 关联序列，应用可能手动调用 nextval 为多个业务字段分配编号。建议使用 pg_get_serial_sequence 函数检查表列与序列的关联：
SELECT pg_get_serial_sequence('public.orders', 'id');
对于非默认关联的序列，可以检查应用代码中对 nextval 的调用，并在发布端和订阅端分别执行相同的序列查询，确保清单完整。
最后需要排查切换后是否仍有旧主库在接收写入。序列校准本身不能解决双主写入冲突。如果应用没有正确切换连接串，或者连接池中仍有旧主库连接，数据可能继续写入旧主库，导致新主库序列即使校准也不准确。正确做法是先通过应用配置或数据库连接管理切断旧主库写入，再校准序列，最后验证新主库可以正常插入。
总结来说，PostgreSQL 逻辑复制不会同步序列，序列修复必须依赖 setval、pg_dump 或切换脚本完成。将序列检查纳入发布订阅切换流程，可以避免大量主键冲突和线上故障。
PostgreSQL逻辑复制序列同步修改时间：2026-08-23 12:38:05