如何查看和分析pg_stat_replication_slots复制槽状态以排查同步问题

PostgreSQL的复制槽机制用来保证主库不会在备库接收WAL之前就清理掉对应的预写日志。当复制出现异常时，数据库管理员往往需要第一时间确认复制槽的真实状态。系统视图pg_stat_replication_slots正是承载这些信息的关键入口，它从主库视角展示了每一个复制槽的存活情况、WAL保留量以及备库反馈进度。

pg_stat_replication_slots核心字段解析

在排查问题前，必须先理解pg_stat_replication_slots中各列的实际意义。该视图每行代表一个复制槽，无论是物理复制槽还是逻辑复制槽都会出现在这里。其中slot_name是复制槽名称，plugin仅对逻辑槽有效表示解码插件，slot_type区分物理或逻辑类型。

active字段最为关键，它显示复制槽当前是否有活跃的连接在使用。如果active为t，说明备库或订阅端正连着主库；若为f，则意味着连接已断开或尚未建立。restart_lsn表示主库为了该槽保留WAL的最小位点，confirmed_flush_lsn则代表逻辑槽消费者已确认刷盘的位点。当active为f且restart_lsn长期不推进，主库就会不断堆积WAL，甚至撑满磁盘。

另外，wal_status显示预留WAL是否达到预留上限，safe_wal_size给出距离触发槽强制丢弃还可保留的空间。对于逻辑槽，spill_txns、spill_count等统计反映了解码过程向磁盘溢出临时文件的情况，这通常与大事务或长事务有关。掌握这些字段，才能从视图中读出复制系统的真实健康度。

使用查询语句监控复制槽状态

仅仅知道字段还不够，实际运维中需要用SQL把异常槽筛出来。最简单的检查是列出所有非活跃且保留WAL较多的槽，这样能快速定位哪些槽可能在拖累主库。下面这段查询按照restart_lsn与当前插入位点之差排序，突出风险槽。

SELECT
    slot_name,
    active,
    slot_type,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal,
    restart_lsn,
    confirmed_flush_lsn,
    wal_status
FROM pg_stat_replication_slots
ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC;

上述代码利用pg_current_wal_lsn获取主库当前写位点，再用pg_wal_lsn_diff计算与restart_lsn的差距，从而估算每个槽卡住时主库被迫保留的日志体积。如果某个槽retained_wal达到数十GB且active为f，基本可以判定备库已经失联或者逻辑订阅端停止消费。

对于逻辑复制，还可以单独观察溢出指标。以下查询聚焦于spill次数偏高的槽，辅助判断是否存在超大事务导致解码阻塞：

SELECT
    slot_name,
    spill_txns,
    spill_count,
    spill_bytes,
    stats_reset
FROM pg_stat_replication_slots
WHERE slot_type = 'logical'
  AND spill_count > 0
ORDER BY spill_count DESC;

通过周期性采集这些查询结果，就能绘制出复制槽状态的时间序列。一旦active从t变为f，或者retained_wal曲线陡增，告警系统便可及时通知运维人员介入，避免主库WAL目录被复制槽锁死。

基于复制槽状态排查同步故障的思路

当pg_stat_replication_slots显示某个物理槽active为f，第一步应检查备库实例是否存活以及主备网络是否通畅。可以在备库使用pg_is_in_recovery确认角色，并观察备库日志中是否有连接主库失败的信息。若网络恢复后active重新变t，且restart_lsn开始向前推进，说明只是瞬时断连，无需特殊处理。

如果active持续为f且restart_lsn不动，就要考虑是否有人误删了备库或者复制槽被闲置。此时若确认对应备库已永久下线，应通过pg_drop_replication_slot释放槽，否则主库WAL将无限堆积。对逻辑槽而言，若confirmed_flush_lsn停滞，多半是订阅端应用进程崩溃或遇到无法消费的行冲突，需要去订阅端查看逻辑复制worker日志。

还有一种隐蔽场景：active为t但restart_lsn推进极慢。这往往意味着备库回放效率低，或者逻辑订阅端正处理一个巨型事务。结合spill相关字段升高，可以推断主库正在把大事务WAL解码溢出到临时文件，消费者跟不上。此时优化订阅端写入性能、拆分大事务，才能让pg_stat_replication_slots中的位点恢复正常流速，保障整个复制体系稳定。

pg_stat_replication_slots复制槽PostgreSQL同步修改时间：2026-08-16 07:52:13