PostgreSQL 逻辑复制怎样按表选择发布内容

如果一个数据库只想把订单和客户资料同步到下游，而不希望把日志、临时表或其他业务域一起带过去，PostgreSQL 逻辑复制的关键不是“启动复制”这四个字，而是先把 publication 的对象范围写窄。CREATE PUBLICATION 可以直接列出表，也可以按 schema 选择表；需要更细的控制时，还能为表加行过滤和发布动作设置。

官方文档：https://www.postgresql.org/docs/current/logical-replication.html

最稳妥的做法是先用 FOR TABLE 明确列出要同步的表，再根据是否需要新表自动加入、是否需要过滤行和是否需要 UPDATE/DELETE，决定要不要扩大到 schema 或增加过滤条件。publication 只是发布定义，订阅端还要刷新才能获得后续范围变化。

先把“按表发布”拆成四个边界

我在设计同步范围时会先写一张小清单：表名、需要发布的 DML、是否允许新表自动加入、以及下游是否需要完整行。这样可以避免直接使用 FOR ALL TABLES 后才发现把不相关数据也暴露给了订阅端。

• 对象边界：只列出真正需要同步的持久表或分区表。
• 动作边界：默认包含 insert、update、delete、truncate，不需要的动作可以删掉。
• 数据边界：行过滤只决定哪些行进入发布，不能把它当成 DDL 同步。
• 权限边界：创建 publication 需要数据库的 CREATE 权限，加入具体表通常还需要表所有权。

用 FOR TABLE 创建只同步指定表的 publication

最容易维护的起点是显式列出表名。下面的示例只发布 sales.orders 和 crm.customers 的数据变更，示例中的对象名可以替换成自己的表。

-- 只把订单和客户表加入 publication，避免把其他业务表一起发布
CREATE PUBLICATION app_data_pub
FOR TABLE sales.orders, crm.customers
WITH (publish = 'insert, update, delete');

-- 查看 publication 当前登记的对象和发布动作
SELECT pubname, puballtables, pubinsert, pubupdate, pubdelete, pubtruncate
FROM pg_publication
WHERE pubname = 'app_data_pub';

这里没有写 FOR ALL TABLES，因此范围不会自动覆盖数据库中的其他表。WITH (publish = ...) 只影响后续 DML；初始数据同步仍然要按订阅端的同步过程处理，不能把它理解为“只复制新增行”。另外，DDL 操作不属于 publication 的发布内容，表结构变更需要单独规划。

用 schema 和 WHERE 调整范围时要留意什么

如果业务表会持续在同一 schema 下增加，schema 级 publication 能减少逐张加表的维护成本；代价是范围更宽，且不能和带列清单的表定义随意混用。行过滤适合只同步满足条件的行，但 UPDATE、DELETE 的过滤表达式还会受到 replica identity 的约束。

-- 让 reporting schema 中的持久表进入 publication；这是更宽的选择范围
CREATE PUBLICATION reporting_pub
FOR TABLES IN SCHEMA reporting
WITH (publish = 'insert, update');

-- 只发布状态为 active 的订单；WHERE 两侧必须保留括号
CREATE PUBLICATION active_orders_pub
FOR TABLE sales.orders
WHERE (status = 'active')
WITH (publish = 'insert, update, delete');

-- 需要缩小或扩大已有范围时，使用 ADD、DROP 或 SET
ALTER PUBLICATION app_data_pub ADD TABLE sales.order_items;
ALTER PUBLICATION app_data_pub DROP TABLE crm.customers;

选择表时还要考虑分区：发布分区表会牵涉现有和未来分区，是否以分区根表身份发布则由 publish_via_partition_root 决定。不要只看 publication 名称判断实际范围，调整后应重新查看定义，并把订阅刷新作为变更的一部分。

订阅端刷新、权限和复制身份是最后三道检查

ALTER PUBLICATION 改变已订阅 publication 的表或 schema 后，订阅端需要执行 ALTER SUBSCRIPTION ... REFRESH PUBLICATION 才能让新增或移除的范围生效。发布端完成定义修改，并不等于订阅端已经重新读取了定义。

-- 发布端调整后，订阅端刷新 publication 的对象清单
ALTER SUBSCRIPTION app_sub REFRESH PUBLICATION;

-- UPDATE 或 DELETE 需要可用于定位行的 replica identity
ALTER TABLE sales.orders REPLICA IDENTITY USING INDEX orders_pkey;

-- 复查 publication 当前登记的表，确认名称与预期一致
SELECT p.pubname, n.nspname AS schema_name, c.relname AS table_name
FROM pg_publication p
JOIN pg_publication_rel r ON r.prpubid = p.oid
JOIN pg_class c ON c.oid = r.prrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE p.pubname = 'app_data_pub';

权限方面，添加表通常要求执行者拥有该表；FOR ALL TABLES 和 FOR TABLES IN SCHEMA 的权限要求更高。若 publication 发布 UPDATE 或 DELETE，目标表还要有合适的 replica identity，列清单或过滤条件也不能把定位所需列排除在外。

几个容易误解的问题

只写 FOR TABLE 就会自动开始复制吗？ 不会。它先定义发布集合，真正的数据传输还需要订阅端订阅该 publication。

把表加入 publication 后，订阅端会立刻看到新表吗？ 不一定。已存在的 subscription 通常需要显式刷新 publication，并按同步策略处理新增对象。

WHERE 过滤能替代权限控制吗？ 不能。它是数据行选择条件，不能取代数据库权限、表所有权和复制连接的安全设计。

什么时候适合 schema 级选择？ 当一个 schema 的表都属于同一同步边界，且团队能接受未来新表也可能进入范围时再使用；否则显式列表更容易审计。

按表选择 publication 的核心是把同步范围写成可审计的对象清单：小范围场景优先使用 FOR TABLE，稳定的业务域可以考虑 TABLES IN SCHEMA，行级需求再增加 WHERE。每次调整后同时检查权限、replica identity 和订阅刷新，才能让发布端定义与下游实际范围保持一致。