错误“requested WAL segment has already been removed”明确表明备库请求的WAL段已被主库清理，根本原因是备库同步滞后超出主库WAL保留能力，需通过日志确认、LSN差值计算和复制槽状态排查定位。

查备库日志确认是否真因WAL被删而掉线

错误信息 requested WAL segment ... has already been removed 是最直接的信号，但它只出现在备库日志里。别急着调参数，先定位是不是这个原因：

• 在备库执行 grep -A 5 "has already been removed" /var/lib/postgresql/*/log/postgresql-*.log（路径按实际调整）
• 如果没匹配到，但看到 could not receive data 或 connection lost，那可能是网络或进程崩溃，不是WAL覆盖问题
• 注意时间戳——若错误发生在备库重启后几秒内，基本可锁定是WAL断档；若发生在持续运行中，则更可能是复制槽卡住或归档延迟

看主库当前WAL位置和备库最后接收点

光看错误不够，得算出“断在哪一段”。关键不是比大小，而是比LSN差值是否超过主库保留能力：

• 在主库查当前WAL位置：SELECT pg_current_wal_lsn();
• 在备库查它最后一次成功应用的位置：SELECT pg_last_xact_replay_location();（注意不是 pg_last_wal_receive_lsn()，后者只代表收到，不代表已重放）
• 用 pg_wal_lsn_diff() 算差值：SELECT pg_wal_lsn_diff('0/12345678', '0/87654321');，结果单位是字节；若超 1GB，且 wal_keep_segments 默认值（通常 128）对应容量约 16GB，那大概率已覆盖

检查复制槽是否活着、是否拖后腿

复制槽（replication slot）是双刃剑：开了能防WAL被删，但一旦卡住，反而会让WAL无限堆积。必须立刻验明正身：

• 主库执行：SELECT slot_name, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;
• active = false 且 restart_lsn 长期不动 → 僵尸槽，WAL不会清理，但也不会帮备库恢复
• active = true 但 restart_lsn 落后主库当前LSN超 10GB → 备库同步严重滞后，可能已卡死在某个大事务上
• 特别注意：confirmed_flush_lsn 比 restart_lsn 还落后？说明备库连确认都发不出，基本是网络层或walreceiver进程挂了

临时绕过WAL断档的实操路径

确认是WAL覆盖后，重建备库不是唯一选项。三种应急方式按风险从低到高排列：

• 若备库只是短暂断连（restore_command 在 recovery.conf（或 postgresql.auto.conf 中的 primary_slot_name）配置正确，备库重启时会自动从归档拉缺失段
• 若归档不可用但主库磁盘还有旧WAL残留（比如 pg_wal/archive_status 里还有 .done 文件）：手动把对应WAL文件拷进备库 pg_wal/ 目录，再重启
• 最激进但最稳：用 pg_basebackup -R 重拉全量，同时指定 --slot=xxx 创建新复制槽，避免下次再掉——这步会中断备库服务，但比等WAL追平快得多

真正容易被忽略的是：WAL断档常伴随时间线（timeline）切换。如果主库发生过failover，备库必须用新时间线的WAL，否则即使LSN对得上也会报错。查主库 pg_control 或 pg_controldata 输出里的 Latest checkpoint's TimeLineID，再核对备库 recovery.signal 里是否指定了正确时间线。