PostgreSQL复制槽监控

PostgreSQL的复制槽（Replication Slot）并不是一个“开启即忘”的组件。很多运维人员直到主库磁盘被撑爆，才发现是某个不再使用的复制槽在作祟。复制槽的本质是WAL（Write-Ahead Log）发送的“水位线”守护者，它确保主库不会在备库或消费者读取之前清理掉所需的WAL文件。一旦消费者掉线或消费过慢，WAL就会在主库不断堆积，最终导致服务不可用。因此，对复制槽的监控，不是简单地看一眼状态，而是要建立一套覆盖空间、进度和延迟的多维度观测体系。

PostgreSQL提供了物理复制槽和逻辑复制槽，它们的监控指标截然不同。物理复制槽用于流复制，对应备库或归档工具。监控它的核心是WAL留存量和重启所需的最小LSN（restart_lsn）与当前写入LSN的差距。逻辑复制槽用于逻辑解码，供逻辑复制或CDC工具消费。除了空间问题，逻辑复制槽的监控还必须深入到解码延迟和事务边界。一个常见陷阱是，逻辑复制槽在遇到长事务时会卡住，即使后续有大量小事务提交，解码位置也无法推进，因为PostgreSQL必须保证事务的原子性解码。

所有监控的起点都是系统视图 pg_replication_slots。执行 SELECT * FROM pg_replication_slots; 能获得最基础的信息，但很多关键细节容易被忽略。slot_type 字段区分物理（physical）和逻辑（logical）。active 字段为 true 表示有消费者正在连接，但 active 为 false 并不一定代表槽已废弃，可能只是消费者暂时断开。真正需要警惕的是 active 为 false 且 xmin 或 catalog_xmin 长时间不推进的槽。对于物理槽，restart_lsn 是备库重放所需的最小WAL地址；对于逻辑槽，confirmed_flush_lsn 是消费者已确认刷盘的位置。监控时，必须对比这些LSN与 pg_current_wal_lsn() 的差值。

这是最紧急的监控项。我们可以通过查询 pg_replication_slots 结合 pg_wal_lsn_diff() 函数来量化WAL堆积量。以下查询能直接显示每个复制槽导致的WAL堆积大小（以字节为单位）：

SELECT
    slot_name,
    slot_type,
    active,
    CASE
        WHEN slot_type = 'physical' THEN
            pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn))
        WHEN slot_type = 'logical' THEN
            pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn))
    END AS wal_retention_size
FROM
    pg_replication_slots;

设置告警阈值时，不能仅看绝对值，还要结合磁盘总容量和WAL生成速率。如果WAL生成速率极高，即使堆积量看起来不大，也可能在几分钟内填满磁盘。因此，需要结合 pg_stat_bgwriter 中的 buffers_clean 和 pg_stat_wal 中的 wal_bytes 计算WAL写入速率，并预测磁盘耗尽时间。

逻辑复制槽的监控远比物理槽复杂。confirmed_flush_lsn 只代表消费者确认位置，但数据库内部可能因为长事务而无法解码到更新位置。必须查询 pg_stat_replication 视图（如果消费者在线）获取 write_lag、flush_lag 和 replay_lag，这些延迟字段直接反映了链路瓶颈。更隐蔽的问题是 catalog_xmin 的停滞。逻辑复制槽需要阻止系统表行的清理，其持有的 catalog_xmin 是 pg_replication_slots 中最关键的字段之一。如果 catalog_xmin 长时间不推进，会导致 pg_stat_all_tables 中 autovacuum 无法清理死元组，最终引发表膨胀和性能雪崩。通过以下查询可以找出被逻辑复制槽阻塞的vacuum：

SELECT
    slot_name,
    catalog_xmin,
    age(catalog_xmin) AS xmin_age_tx
FROM
    pg_replication_slots
WHERE
    slot_type = 'logical'
    AND catalog_xmin IS NOT NULL;

当 xmin_age_tx 值异常增大时，说明存在长事务或复制槽消费停滞，需要立即排查消费者端。

一个 inactive 的复制槽如果长期无人认领，就是一颗定时炸弹。我们需要定期巡检那些非活跃但占用大量WAL的槽。但要注意，对于逻辑复制槽，即使 active 为 false，只要 confirmed_flush_lsn 在推进，说明消费者采用轮询模式，这是正常的。真正的“僵尸槽”特征是：active 为 false，且 restart_lsn 或 confirmed_flush_lsn 在连续多次检查中完全不变。可以创建一个监控表，定期快照 pg_replication_slots 的LSN位置，通过对比变化来识别僵尸槽。在确认槽已废弃后，使用 pg_drop_replication_slot() 清理，但务必先确认没有消费者正在重连，否则会导致备库重建或数据同步中断。

仅依赖数据库视图是不够的，有时复制槽可能因为bug或异常状态导致WAL保留，但在视图中显示正常。直接监控 pg_wal 目录下的文件数量和总大小是最后的防线。可以设置一个定时任务，当 pg_wal 目录大小超过总磁盘空间的某个阈值（如60%）时，触发最高级别告警。同时，结合 pg_archivecleanup 或 pg_rewind 的相关日志，检查是否有归档失败导致WAL堆积的情况，因为归档失败也会间接影响复制槽的清理行为。

一个硬核的监控体系需要分层实现。第一层，使用Prometheus的postgres_exporter采集 pg_replication_slots 和 pg_stat_replication 指标，对 wal_retention_bytes 和 replication_lag 设置分级告警。第二层，在数据库内部部署定时任务，使用 plpgsql 编写存储过程，检查 catalog_xmin 年龄和WAL堆积速率，当超过阈值时主动向监控系统推送事件或执行 pg_terminate_backend() 终止阻塞进程（需谨慎配置白名单）。第三层，建立复制槽生命周期管理流程，任何新建的复制槽必须在配置管理系统中注册，并绑定负责人和自动过期策略，从源头杜绝遗忘。

在高并发环境中，逻辑复制槽的解码性能可能成为瓶颈。如果解码速度跟不上WAL生成速度，即使消费者确认及时，confirmed_flush_lsn 也会落后。此时需要监控 pg_stat_replication 的 write_lag 而非仅看 confirmed_flush_lsn。对于分区表，逻辑复制可能会产生大量的子表变更，如果复制槽没有正确配置 publish_via_partition_root，会导致解码出大量冗余数据，加剧延迟。监控时应单独统计分区表的WAL生成量，并与复制槽的吞吐量进行对比。

对于逻辑复制，PostgreSQL提供了 pg_replication_origin_* 系列函数来追踪复制源。通过 pg_replication_origin_session_setup 和 pg_replication_origin_progress 可以获取更精确的复制位点。在双向复制或多主复制场景下，使用这些函数能定位到是哪个节点的哪个槽导致了循环复制或WAL堆积。监控脚本可以定期调用 pg_replication_origin_progress() 并与本地LSN对比，实现跨节点的延迟监控。

监控的最终目的是自动化处理。当检测到非活跃复制槽的WAL保留量超过阈值且持续时间超过N分钟，可以自动触发清理流程。但直接删除风险太高，更稳妥的方案是先调用 pg_replication_slot_advance() 尝试推进槽的位置（仅限逻辑槽），如果推进失败，再结合 pg_terminate_backend() 终止可能僵死的walsender进程。如果所有尝试无效，再通知人工介入。这套自愈逻辑可以写成Python脚本，由监控系统的webhook触发，确保在凌晨故障时能第一时间止损。