SQL max_replication_slots 的逻辑槽位泄漏监控脚本模板

应定期扫描pg_replication_slots，筛选active=false且wal偏移超1gb的逻辑复制槽，结合业务下线证据确认废弃后，用replication权限用户执行安全drop命令清理，避免仅依赖槽数量告警。

max_replication_slots 超限后 pg_replication_slots 不清空怎么办

postgresql 的逻辑复制槽（logical replication slot）一旦创建，即使客户端断连、消费者崩溃或未消费，槽位仍会持续保留 WAL，导致 pg_replication_slots 里残留大量 active = false 但 restart_lsn 卡住的槽。这不是 bug，是设计行为——槽只靠显式 pg_drop_replication_slot() 清理。

常见错误现象：Error: all replication slots are in use；pg_stat_replication 为空但 pg_replication_slots 有十几个 inactive 槽；WAL 文件持续堆积，磁盘告警。

• 必须定期扫描 pg_replication_slots，过滤出 active = false 且 confirmed_flush_lsn IS NOT NULL（说明曾正常工作过）但长期未推进的槽
• 判断“长期”不能只看时间戳（catalog_xmin 或 create_time 不可靠），应结合 restart_lsn 和当前 pg_current_wal_lsn() 差值：差值 > 1GB WAL 通常意味着卡死
• 避免误删正在被其他服务（如 Debezium、wal2json 客户端）重建中的槽——加一层 slot_name ~ '^myapp_.*' 白名单匹配，别用 LIKE '%_old' 这类模糊规则

用 SQL 查出待清理的逻辑槽并生成 DROP 语句

直接查表只能看到状态，真正要操作得拼出安全可执行的 DROP 命令。关键不是“找出所有 inactive”，而是“找出可确认废弃的 inactive”。

使用场景：运维巡检脚本、prometheus exporter 数据采集前预处理、ansible 批量清理任务。

• 先算 WAL 偏移量：(pg_current_wal_lsn() - restart_lsn) > 1073741824（1GB），单位是字节，注意 PostgreSQL 10+ 支持 LSN 减法
• 排除系统槽：slot_type = 'logical' 且 plugin IN ('pgoutput', 'wal2json', 'decoderbufs')，避免误碰物理复制槽或内置插件
• 输出格式必须带引号和条件检查：

  SELECT format('SELECT pg_drop_replication_slot(''%I'') WHERE EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = ''%I'' AND active = false);', slot_name, slot_name) FROM pg_replication_slots WHERE slot_type = 'logical' AND active = false AND (pg_current_wal_lsn() - restart_lsn) > 1073741824;

在 cron 里跑监控脚本时的权限与事务陷阱

用普通用户执行 pg_drop_replication_slot() 会报 ERROR: must be superuser or replication role to drop replication slot，但给应用账号 superuser 权限又太危险。

性能影响小，但兼容性风险集中：PostgreSQL 12 之前不支持在事务块里调用 pg_drop_replication_slot()，而很多脚本默认套了 BEGIN; ...; COMMIT;。

• 运行脚本的数据库用户必须有 REPLICATION 属性（ALTER USER mymonitor WITH REPLICATION;），无需 superuser
• 绝对不要在事务中执行 DROP —— 每条 pg_drop_replication_slot() 必须独占一个隐式事务
• 加超时控制：psql 调用时加 -v ON_ERROR_STOP=1 --set=statement_timeout=30s，防止某个卡死槽阻塞整个清理流程
• 日志里记录 slot_name 和 restart_lsn，别只记 “dropped 3 slots” —— 后续审计要能回溯到具体哪个槽、为什么删

为什么不能只依赖 max_replication_slots 值做告警阈值

max_replication_slots 是硬上限，但槽位泄漏的实质问题是 WAL 积压，不是数字接近上限。等报错才处理，往往已丢数据或触发主库 OOM。

容易踩的坑：监控项只采集 count(*) FROM pg_replication_slots，设阈值为 max_replication_slots * 0.8。这完全忽略槽的活性——可能 10 个槽里 9 个是僵尸，1 个是活的，但 WAL 早把磁盘打爆了。

• 核心指标应该是 pg_current_wal_lsn() - restart_lsn 的最大值（单位字节），不是槽数量
• 配合 pg_replication_slots.catalog_xmin 看是否拖慢 vacuum（若 catalog_xmin 异常小，说明该槽阻碍了系统表清理）
• PostgreSQL 15+ 可用 pg_replication_slots.advanced_cleanup（需开启），但默认关闭，别假设它自动帮你兜底

最麻烦的点不在怎么删，而在怎么确认“这个槽真的没人用了”。业务方口头说“不用了”，不如看 confirmed_flush_lsn 三个月没动、下游 kafka topic 没新消息、对应服务进程已下线这三个证据链。缺一不可。