复制延迟扩大后，pg_replication_slots 中的 wal_status 变成 lost，订阅端或备库无法继续读取需要的 WAL。此时不能只把延迟清零；必须先确认缺失的 WAL 是否还能从可信归档取得，并按复制类型设计恢复路径。
lost 表示这个复制槽已不可用。 切勿在未确认消费端状态时删除槽或直接跳过缺失日志，否则可能造成数据断档。
查询复制槽与保留压力
在主库查看槽状态、活动情况及 WAL 积压：
SELECT slot_name, slot_type, active, restart_lsn, wal_status,
safe_wal_size, invalidation_reason
FROM pg_replication_slots;列会随 PostgreSQL 版本变化，先以当前实例文档和 \d pg_replication_slots 为准。wal_status 的 reserved、extended、unreserved、lost 反映所需 WAL 是否仍受保护；lost 不等于数据库本体已经损坏。
查清WAL为什么被移除
检查 max_slot_wal_keep_size、磁盘空间、复制连接和消费端故障。该参数为 -1 时，复制槽可能无限保留 WAL，磁盘风险反而增大；设置上限则可能在检查点后让落后的槽失效。
SHOW max_slot_wal_keep_size;
SHOW wal_keep_size;
SELECT pg_current_wal_lsn();不要盲目调大上限而忽略磁盘容量和消费速度。 先找出延迟是网络、从库停机还是消费程序阻塞。
区分物理与逻辑复制恢复
物理备库如果缺失的 WAL 可从已验证的归档连续取得，可按既有恢复流程重放；否则需以一致性基础备份重建备库，再配置合适的复制槽。逻辑复制的消费者需按其快照、复制原点与目标数据一致性重新初始化。
不能把新槽直接接到旧消费位置就宣称数据完整。 在选择重建前保存消费端位点、备份和业务对账信息。
谨慎处理失效槽
确认相关消费者已迁移、重建且不再引用旧槽后，才能评估删除失效槽并按受控流程建立新槽。删除复制槽是有影响的操作，不应为了释放磁盘先执行。
运维演练可在 萤光云 或 LightNode 的隔离实例完成，使用脱敏数据和明确的备份恢复点。
建立提前预警
持续监测 wal_status、safe_wal_size、restart_lsn 与当前 WAL 位点的差距，以及磁盘剩余空间。报警阈值应结合实际 WAL 生成速率，而不只是固定的字节数。
看到 unreserved 就应立即核查，不能等槽已经 lost 才处理。 同时检查消费者心跳和复制延迟。
恢复后做数据验收
重新读取槽状态，核对消费者位置与上游一致性，并验证关键业务表的行数和抽样数据。物理备库还需确认重放位点持续前进；逻辑复制需要核对初始同步与后续变更。
验收标准是复制持续推进且业务数据对账通过，而非仅仅看到槽重新处于 active。
FAQ
把 max_slot_wal_keep_size 调大能让 lost 槽恢复吗？ 不能；已经删除的必需 WAL 不会因调参重新出现。
可以直接删除 lost 槽吗？ 先确认消费端的恢复和切换方案；删除可能破坏现有引用与追溯链。
温馨提示
复制恢复涉及业务数据完整性。任何重建和位点切换都应保留可验证备份，并安排业务对账。
