PostgreSQL逻辑复制如何过滤不需要同步的表？

PostgreSQL的逻辑复制基于发布订阅模型，发布端把WAL日志解析成逻辑变更记录，订阅端接收后回放到本地表。默认情况下，很多人习惯直接对整个数据库执行CREATE PUBLICATION ... FOR ALL TABLES，结果就是库里所有的表都会进入同步队列。对于一个包含几百张表的库来说，如果其中相当一部分是操作日志表、审计表或者中间结果表，这些数据同步到订阅端毫无意义，却会持续消耗网络带宽和磁盘IO。所以掌握如何在逻辑复制中过滤掉不需要的表，是搭建同步链路时必须处理好的一个环节。

一、通过Publication的表清单精确控制同步范围

逻辑复制过滤表最直接的方式，就是不要使用FOR ALL TABLES，而是在创建发布时明确列出需要同步的表。发布对象支持库级别、表级别和schema级别三种粒度，表级别是最常用的控制手段。下面是一个只发布两张业务表的例子：

-- 创建发布，只包含指定的两张表
CREATE PUBLICATION my_pub FOR TABLE orders, customers;

-- 后续需要追加或移除表时，使用ALTER语句动态调整
ALTER PUBLICATION my_pub ADD TABLE products;
ALTER PUBLICATION my_pub DROP TABLE audit_log;

-- 查看当前发布包含哪些表
SELECT * FROM pg_publication_tables WHERE pubname = 'my_pub';

这种白名单方式的好处是边界清晰，发布端定义了什么，订阅端就收到什么，排查问题的时候查一下pg_publication_tables视图就能确认范围。需要注意的是，如果一个表后来被加入发布，但订阅端还没有建立对应的表映射，新表的数据不会自动同步，需要执行ALTER SUBSCRIPTION ... REFRESH PUBLICATION刷新订阅信息，必要时还要加上COPY DATA选项补齐存量数据。

反过来，黑名单的思路在PostgreSQL的逻辑复制里并不直接支持，也就是说没有一个语法可以写“除了某张表以外全部同步”。想实现类似效果，只能通过schema级别发布来间接达成：把需要同步的表集中放到独立的schema里，然后CREATE PUBLICATION my_pub FOR ALL TABLES IN SCHEMA business;，把日志类表留在public等其他schema中。这种组织方式在表数量较多的系统里尤其值得推荐，同步边界和业务边界保持一致，后期维护成本低很多。

二、订阅端表结构与初始数据拷贝的处理

逻辑复制不复制DDL，订阅端必须提前建好表结构。如果发布端库里表很多，手工建表容易遗漏，通常的做法是用pg_dump只导出需要同步的那些表的结构。配合前面的发布清单，导出命令可以这样写：

# 只导出两张表的结构，不导出数据
pg_dump -h 源库地址 -U postgres -d sourcedb \
  --schema-only --table=orders --table=customers \
  -f schema.sql

# 在订阅端执行结构文件
psql -h 订阅端地址 -U postgres -d targetdb -f schema.sql

这里要提醒一点，如果发布端是通过pg_dump全库导出再剔除某些表，注意--table参数支持通配符写法，例如--table='business.*'可以一次性导出整个schema下的所有表，和schema级别的发布配合使用非常顺手。

建好结构后创建订阅，订阅端会先做初始数据拷贝（COPY），再进入流式回放阶段。初始拷贝期间订阅会为每个同步的表各起一个worker进程，如果表数据量很大，建议把max_logical_replication_workers和max_sync_workers_per_subscription调大一些，否则可能出现拷贝排队等待的情况。对于明确不需要存量数据的表，还可以在创建订阅时把表的状态设为READY之前手工干预，跳过初始拷贝直接进入增量回放，不过这种操作要谨慎，仅适合订阅端已经有等价数据的场景。

三、复制标识缺失导致的同步故障

过滤好表清单之后，还有一个高频报错和表的选择密切相关：UPDATE或DELETE操作无法复制，日志中提示"cannot be deleted from publication"或者"no replica identity"。原因是逻辑复制在发布端需要通过表的复制标识来定位旧元组，默认只有主键才能充当复制标识。如果一张表没有主键，又被加入了发布并执行了更新或删除，同步就会中断。

解决思路有三种。第一种是给表补主键，这是最稳妥的方案。第二种是设置REPLICA IDENTITY FULL，让WAL记录整行旧值：

-- 无主键表设置完整复制标识
ALTER TABLE audit_log REPLICA IDENTITY FULL;

-- 或者指定一个唯一索引作为复制标识
ALTER TABLE audit_log REPLICA IDENTITY USING INDEX idx_audit_log_uid;

不过FULL模式的代价不小，发布端WAL体积增大，订阅端回放时每条变更都要做全表匹配查找，性能下降明显。所以对于高频更新的表，宁可加一列序列主键，也不要长期使用FULL模式。第三种思路就是干脆不把这种无主键表放进发布范围，如果它本来就是日志表，正好符合我们前面讲的过滤策略。

四、监控与常见运维命令

链路跑起来之后，过滤是否生效需要通过系统视图确认。pg_stat_subscription记录每个订阅的回放进度，可以查看最近收到和回放的事务LSN；发布端通过pg_replication_slots检查复制槽的状态，重点盯住active字段和pg_wal目录的大小。逻辑复制的一个经典隐患是订阅端长时间宕机时，发布端会保留WAL不被回收，磁盘可能被撑爆，所以对不活跃的订阅要及时清理对应的复制槽。

常用的运维命令汇总如下：

-- 刷新订阅的发布内容（新增或移除表后执行）
ALTER SUBSCRIPTION my_sub REFRESH PUBLICATION;

-- 刷新时同时拷贝新表的存量数据
ALTER SUBSCRIPTION my_sub REFRESH PUBLICATION WITH (copy_data = true);

-- 查看订阅端的表同步状态
SELECT * FROM pg_subscription_rel;

-- 订阅不再使用时，先禁用再删除，避免残留复制槽
ALTER SUBSCRIPTION my_sub DISABLE;
DROP SUBSCRIPTION my_sub;

总的来说，PostgreSQL逻辑复制的表过滤核心在于发布清单的设计。优先采用schema级别的白名单管理，配合pg_dump的结构导出和复制标识检查，就能搭建出一条只传输必要数据、故障率低、便于监控的同步链路。遇到同步异常时，先查发布表清单，再查复制槽和订阅回放状态，按照这个顺序排查基本能覆盖绝大多数问题。

PostgreSQL逻辑复制Publication修改时间：2026-09-06 14:46:35