逻辑复制过滤策略的基础与监控盲区
PostgreSQL的逻辑复制通过发布（Publication）和订阅（Subscription）模型，让用户能够选择性地复制数据。发布端可以指定哪些表被发布，还可以进一步通过INSERT、UPDATE、DELETE操作类型进行过滤，甚至在创建发布时使用WHERE子句定义行级过滤器。这些过滤策略的配置直接决定了下游数据的一致性。例如，如果某个关键业务表被误操作移出了发布列表，那么所有针对该表的修改都不会同步到订阅端，而数据库管理员可能在数小时后才发现数据缺失。
然而，PostgreSQL并没有内置的监控面板来直接展示当前活跃的过滤策略。大多数监控方案都集中在复制槽的WAL堆积量、延迟等指标上，很少关注“哪些表正在被复制”这一根本性问题。要弥补这个空白，我们需要主动查询系统目录表，并设计一套可以周期性检查过滤规则完整性的机制。接下来就详细展开如何从元数据层面掌握过滤策略，并通过自定义监控脚本实现自动告警。
从系统表中提取当前生效的过滤规则
PostgreSQL将发布信息存储在pg_publication系统表中，而发布与表的对应关系则记录在pg_publication_rel中。要查看某个数据库中的所有发布及其包含的表，可以执行如下查询：
SELECT p.pubname AS 发布名,
n.nspname AS 模式名,
c.relname AS 表名,
p.pubinsert AS 复制INSERT,
p.pubupdate AS 复制UPDATE,
p.pubdelete AS 复制DELETE,
p.pubtruncate AS 复制TRUNCATE
FROM pg_publication p
LEFT JOIN pg_publication_rel pr ON pr.prpubid = p.oid
LEFT JOIN pg_class c ON c.oid = pr.prrelid
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
ORDER BY p.pubname, n.nspname, c.relname;
上述查询不仅能列出发布中的表，还能显示该发布允许复制的操作类型。需要注意的是，如果一个发布设置为“所有表”（即创建时没有指定表列表），那么pg_publication_rel中就不会有对应记录。此时过滤策略是所有非系统表都会被复制，操作类型默认全部开启。为了捕捉这种情况，可以结合pg_publication中的puballtables字段进行判断。另外，行级过滤条件存储在pg_publication_rel的prqual列中，它对应的是一个pg_node_tree类型的表达式树，直接查询比较晦涩，但我们可以通过pg_get_publication_tables函数更友好地获取：
SELECT pubname,
schemaname,
tablename,
attnames,
rowfilter
FROM pg_get_publication_tables('your_publication_name');
利用这些元数据，我们可以将期望的过滤策略编码为一个参考配置表，然后周期性地与实际查询结果进行对比。一旦发现差异，比如某个表被从发布中移除，或者操作类型的过滤发生变化，就触发告警。这是监控过滤策略的核心思路。
结合复制状态视图发现数据同步异常
仅仅检查发布端的元数据还不够，因为即使过滤策略看似正常，复制进程本身可能已经停止或出现延迟。pg_stat_replication视图提供了当前所有WAL发送进程（包括逻辑复制）的状态信息，其中application_name与订阅名称对应，state字段显示复制是否在进行，pg_wal_lsn_diff可以计算发送端与接收端之间的字节延迟。但这些信息并不能直接告诉我们“哪些表没有被复制”。
要打通元数据与运行时状态的关联，我们可以将发布中的表清单与订阅端实际接收到的数据变化进行核对。一种简单有效的办法是在发布端创建一个心跳表，例如replication_heartbeat，并确保该表始终在发布列表中。然后定期向该表写入带时间戳的记录，在订阅端检查最新记录的时间是否在允许的延迟范围内。若心跳丢失，意味着过滤策略可能已将该表排除，或者复制进程整体异常。当然，心跳表需要被显式地纳入发布，如果发布是“所有表”模式，新创建的表会自动加入，此时心跳表自然有效。对于明确指定表列表的发布，务必把心跳表加入发布，否则心跳机制本身就会失效。
利用事件触发器与自定义函数实现变更告警
如果我们希望实时监控过滤策略的变更，比如有人执行了ALTER PUBLICATION ... ADD/DROP TABLE，可以使用PostgreSQL的事件触发器（Event Trigger）。当DDL命令执行时，事件触发器可以在ddl_command_end事件中捕获到相关操作。通过编写一个PL/pgSQL函数，在函数中解析pg_event_trigger_ddl_commands()返回的命令信息，过滤出针对出版物的ALTER操作，然后将变更详情记录到日志表或通过NOTIFY发送告警。
下面是一个事件触发器的示例框架，它会在所有DDL操作完成后被调用，检测是否修改了发布：
CREATE OR REPLACE FUNCTION monitor_publication_changes()
RETURNS event_trigger AS $$
DECLARE
r record;
BEGIN
FOR r IN
SELECT object_type, object_identity, command_tag
FROM pg_event_trigger_ddl_commands()
WHERE command_tag = 'ALTER PUBLICATION'
LOOP
RAISE WARNING '发布策略变更: % , 对象: % , 命令: %',
r.object_type, r.object_identity, r.command_tag;
-- 在这里可以插入自定义告警逻辑，如写入审计表或调用外部通知
END LOOP;
END;
$$ LANGUAGE plpgsql;
CREATE EVENT TRIGGER trg_publication_monitor
ON ddl_command_end
EXECUTE FUNCTION monitor_publication_changes();
这个触发器会在发布被修改时发出警告，但如果想要记录具体添加或删除了哪些表，就需要进一步解析命令文本。对于简单的增加/删除表操作，可以使用pg_event_trigger_ddl_commands()返回的command字段进行字符串匹配。更稳健的方式是结合pg_publication_rel的快照对比，在触发器执行结束后，查询最新的表列表并与之前保存的基线对比，发现差异再告警。此外，事件触发器无法捕获通过直接修改系统表（极不推荐）进行的变更，因此常规的元数据监控仍不可或缺。
构建自动化监控闭环
将上述方法组合起来，可以形成一个完整的监控体系。首先，使用一个定时任务（例如pg_cron或操作系统cron）每分钟执行一次检查脚本：该脚本查询pg_publication和pg_publication_rel，并与预期配置表进行比对；同时检查心跳表的最新时间戳。其次，通过事件触发器在DDL层面捕获实时改动。最后，将所有检查结果上报到监控平台（如Prometheus + Grafana、Zabbix等）或发送邮件、钉钉通知。
在实现告警逻辑时，建议不要仅依赖系统默认的WAL堆积监控，因为它可能没法区分“没有数据变化”和“数据被过滤掉”两种情况。只有把过滤策略本身作为一等公民来监控，才能在第一时间发现“明明有业务写入，但订阅端就是没有数据”这种诡异问题。通过这套方案，PostgreSQL的逻辑复制不再是一个黑盒，而是透明、可控的数据分发管道。
PostgreSQL逻辑复制过滤策略修改时间：2026-08-12 13:27:50