PostgreSQL的逻辑复制自10版本引入后，成为跨版本升级、部分数据同步、读写分离等场景的重要工具。发布端通过
CREATE PUBLICATION
定义要复制的表集合，默认情况下将发布内所有表的INSERT、UPDATE、DELETE操作全部发送给订阅端。但生产环境中经常遇到需求变化：一开始整库同步，后来只需要同步几张核心表；或者原本同步全量数据，后来发现某些大表的历史数据没必要复制，只想同步新增数据。在这种情况下，如果直接在发布端执行ALTER PUBLICATION ... SET TABLE ...
或者修改行过滤条件，订阅端可能立刻停止接收原有表的变更，造成两侧数据永久不一致。因此，在线调整逻辑复制过滤策略需要一套不中断业务的工程方法。
首先要理解逻辑复制过滤的三种粒度：表级过滤（发布中包含哪些表）、行级过滤（通过WHERE条件只复制满足条件的行）、列级过滤（只复制指定的列）。其中列级过滤只能在创建发布时指定，无法在线修改；行级过滤可以通过修改发布的WHERE子句来调整，但修改后只会影响之后产生的变更，历史数据不会自动重新筛选；表级过滤则直接控制发布集，变动最大。在线调整的核心思路是：先创建符合新过滤条件的临时发布，然后让订阅端在逻辑上切换到该发布，完成数据初始化对齐后，再清理旧发布。整个过程中原订阅连接可以继续保持，实现平滑过渡。
逻辑复制过滤的核心机制
逻辑复制的工作流程可以概括为：发布端通过walsender进程读取WAL日志，将其解码为逻辑变更记录，再通过复制协议发送给订阅端的apply进程。发布中的过滤条件在解码阶段生效，也就是说，发布端的
pgoutput
插件会根据发布定义生成对应的复制标识（replica identity）和数据行。表级过滤决定了哪些表的WAL记录会被解码和发送；行级过滤则在解码每个表的变更时，根据WHERE条件判断该行是否满足复制要求。这意味着过滤策略的调整必须与WAL解码过程保持一致，否则会出现某些行变更未被正确解码的情况。例如，创建一个带行过滤的发布：
-- 创建发布，只同步 orders 表中 status = 'active' 的行 CREATE PUBLICATION pub_orders_active FOR TABLE orders WHERE (status = 'active');
这个发布只会把
orders
表中status为active的行的变更发送给订阅端。如果后续业务需求变为只需要同步status为'completed'的行，直接执行ALTER PUBLICATION pub_orders_active SET TABLE orders WHERE (status = 'completed')
是可行的，但已经复制到订阅端的旧active行数据不会自动被删除，需要手工清理。更重要的是，如果在修改过滤条件的同时有大量并发事务正在写入，可能出现部分事务的变更被旧的过滤条件捕获，而另一些被新条件捕获，导致订阅端数据出现中间状态。因此，在线调整必须结合事务一致性检查。另外，表级过滤对复制槽的影响也很大。每个发布对应一个复制槽（replication slot），复制槽记录了订阅端已经消费到的LSN位置。如果从发布中移除某些表，这些表在WAL中的变更记录仍然可能被发送给订阅端，但订阅端apply进程会因为目标表不存在而报错。所以直接移除表后，需要重建复制槽并重新初始化订阅，这就是为什么在线调整表级过滤通常采用新建发布加新建订阅的方式。
在线调整过滤策略的实施步骤
假设当前场景：发布端有一个发布
pub_all
，包含表users
、orders
、products
，订阅端通过订阅sub_all
同步这三张表。现在需要调整为只同步users
和orders
，且对orders
增加行过滤条件order_date > '2025-01-01'
。业务要求不停机，不影响正在进行的同步。第一步，在发布端创建新的发布，包含目标表及过滤条件。注意不要包含被移除的表
products
。-- 创建新发布，满足新的过滤策略 CREATE PUBLICATION pub_new FOR TABLE users, orders WHERE (orders.order_date > '2025-01-01');
第二步，在订阅端创建新的订阅，指向新发布，但暂时不启用自动初始化。之所以不立即初始化，是因为初始化会进行一次全量数据复制，如果此时原订阅还在同步，可能造成数据重复或锁冲突。可以先将新订阅创建为禁用状态，或者使用
CREATE SUBSCRIPTION
的WITH (enabled = false)
选项。-- 在订阅端创建新订阅，暂不启用 CREATE SUBSCRIPTION sub_new CONNECTION 'host=publisher port=5432 dbname=source user=repl_user password=secret' PUBLICATION pub_new WITH (enabled = false);
第三步，等待一个合适的低峰窗口，执行数据初始化对齐。可以先手工在订阅端创建目标表结构（如果新发布中的表结构与原订阅中的一致，可以跳过这一步），然后启用新订阅，触发全量数据复制。此时原订阅仍在运行，但新订阅的初始同步会复制一份当前快照的数据。由于两个订阅同时从发布端读取数据，需要注意复制槽的冲突：原发布和新发布各自使用独立的复制槽，互不影响。
-- 启用新订阅，开始初始同步 ALTER SUBSCRIPTION sub_new ENABLE;
第四步，验证新订阅的数据一致性。通过对比两侧表的行数、关键数据哈希值等，确认新订阅已经追上发布端的当前状态。可以使用
pg_stat_subscription
视图查看新订阅的状态，确保其处于streaming
状态且没有报错。第五步，切换业务读取或应用侧连接。如果应用直接访问订阅端数据库，需要将读流量切换到新订阅的库（或新订阅所在实例的对应表）。如果订阅端是数据仓库或报表库，可以并行运行一段时间，确认无误后再停用原订阅。
第六步，停用并删除原订阅和原发布。停用原订阅时注意不要立即删除，可以先
ALTER SUBSCRIPTION sub_all DISABLE;
然后观察一段时间的日志，确保没有应用还在依赖原订阅的数据。确认无误后删除原订阅和原发布，释放复制槽。-- 停用原订阅 ALTER SUBSCRIPTION sub_all DISABLE; -- 确认无影响后删除 DROP SUBSCRIPTION sub_all; -- 在发布端删除旧发布 DROP PUBLICATION pub_all;
过滤策略变更的风险与应对
在线调整过滤策略最大的风险是数据不一致，尤其是行过滤条件发生变化后，历史数据的处理。行过滤只影响变更流的后续数据，不会自动删除订阅端已有的不满足新条件的旧数据。例如之前同步了status为active的订单，现在改为只同步completed订单，那么订阅端会继续保留之前同步过来的active订单，并且不再接收新的active订单变更。如果业务逻辑假设订阅端只包含completed订单，就会出错。因此，在调整行过滤条件后，需要手工清理订阅端不符合新条件的历史数据，或者重新初始化全量同步。
另一个常见风险是主键冲突。如果新发布中包含的行在订阅端已经存在但内容不同（比如因为之前不同的过滤条件导致某些行从未同步，现在又要同步该行），初始同步时可能因为主键冲突而失败。解决方法是先删除订阅端对应的冲突行，或者使用
ALTER TABLE ... REPLICA IDENTITY FULL
配合delete操作。另外，序列值不同步也是一个隐蔽问题：如果发布端使用自增主键，订阅端也使用相同的序列初始值，但两侧写入操作不同步，可能导致主键冲突。对于只读订阅端，建议将序列设为与发布端相同但后续不递增，或者使用UUID主键。复制槽残留会导致WAL无限增长。在删除原订阅之前，如果原发布仍然存在，对应的复制槽会一直保留，即使订阅已禁用。因此，在确认数据迁移完成后，必须删除原订阅，让发布端自动清理复制槽。可以通过查询
pg_replication_slots
确认没有孤儿槽。此外，在切换期间，如果新订阅初始同步耗时较长，发布端会同时保留两个复制槽，需要确保磁盘空间足够容纳这段时间内的WAL。实战案例与性能考量
以一个电商场景为例：生产库中有
orders
、order_items
、users
、logs
四张表，其中logs
表增长极快，只在前端展示最近30天的日志，因此不需要全量同步到分析库。初始逻辑复制时误将logs
也加入了发布，导致分析库数据膨胀，同步延迟增大。通过上述在线调整方法，新建一个不包含logs
的发布，并利用初始同步重新复制了其他三张表。调整后，分析库的磁盘占用下降了约40%，同步延迟从分钟级降低到秒级。性能方面，行过滤会增加发布端解码开销，因为每个变更行都需要评估WHERE条件。对于高写入频率的表，复杂的过滤条件可能导致解码延迟上升。建议对过滤条件涉及的列建立索引，并定期通过
EXPLAIN
检查过滤条件的执行成本。另外，列级过滤虽然可以减少网络传输和订阅端存储，但无法在线修改，如果未来需要调整列，必须重建发布和订阅。因此，在设计初始发布时应尽量包含未来可能需要的列，避免后期返工。在线调整逻辑复制过滤策略并不是一个命令就能完成的操作，而是一套包含发布重建、订阅切换、数据验证、清理回滚的流程。理解其底层机制，才能在各种意外情况下做出正确的决策。如果时间窗口允许，建议先在测试环境完整演练一遍，记录每一步的耗时和潜在问题，再在生产环境执行。
PostgreSQL逻辑复制复制过滤在线变更修改时间：2026-10-05 09:25:01