文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程故障排查流程图4. 方案实施主备切换演练1. 切换前检查2. 切换操作3. 切换后验证4. 回切流程演练指标对比5. 结果对比6. 风险与复盘7. 常见问题与排查误区误区一WAL 积压导致磁盘满误区二网络抖动误判为备库问题误区三备库回放慢的误判每日一句正能量“好心情是自己给的好运气是吸引来的你的磁场就是你的运气。”积极、开放的状态会提升你的觉察力、亲和力和行动力从而“吸引”更多机会与人脉。运气往往是当你准备好时刚好识别并抓住了机会。1. 背景与问题生产数据库采用流复制架构业务高峰期间监控告警显示复制延迟由毫秒级迅速升至数十秒。虽然主库事务正常提交但备库回放明显滞后存在RPO风险。为避免故障扩大需要建立标准化排查路线从监控、日志、SQL和网络逐步定位原因。2. 环境与数据PostgreSQL 16一主一备WAL归档开启数据规模1.5TB专线1Gbps目标RTO≤30分钟RPO≤5分钟关键SQLSELECTapplication_name,state,write_lag,flush_lag,replay_lagFROMpg_stat_replication;SELECTnow()-pg_last_xact_replay_timestamp();监控关注WAL生成速率replay_lag网络RTT磁盘IOCPU利用率3. 复现过程故障注入使用限速工具模拟链路拥塞。持续执行批量写入。观察复制延迟变化。收集数据库日志、系统监控和SQL输出。时间线显示网络带宽下降后WAL发送积压随后备库磁盘IO升高回放速度进一步降低。时间线显示网络带宽下降后WAL发送积压随后备库磁盘IO升高回放速度进一步降低。故障排查流程图基于上述复现过程可梳理出如下标准排查流程是否是否监控告警复制延迟突增检查复制状态replay_lag 是否持续升高?排查网络带宽与 RTT检查主库 WAL 发送检查备库磁盘 IO 与慢 SQLIO 或 SQL 是否异常?优化备库回放与索引核对网络与 WAL 连续性恢复网络并重新验证同步确认 replay_lag 恢复、数据一致流程说明告警触发后先确认复制状态与延迟指标再按“网络 → 备库IO → WAL”的顺序逐层排查定位根因后恢复并验证同步最终确认数据一致性与RPO/RTO达标。4. 方案实施部署/演练流程检查复制状态。核对WAL是否连续。排查网络带宽与RTT。检查备库IO及慢SQL影响。恢复网络并重新验证同步。验证SQLSELECTpg_is_in_recovery();SELECTnow()-pg_last_xact_replay_timestamp();检查清单WAL发送正常replay_lag恢复网络稳定数据一致性通过切换演练通过主备切换演练1. 切换前检查操作确认主库与备库复制状态正常replay_lag处于可接受范围。核对 WAL 归档是否连续备库已接收并回放最新 WAL。检查主备网络 RTT 与带宽确认链路稳定。确认业务低峰期窗口并提前通知相关方。预期结果主备数据一致pg_stat_replication显示statestreamingreplay_lag接近 0。注意事项切换前务必确认备库磁盘空间充足避免回放积压导致切换后写入失败。2. 切换操作操作在备库执行pg_ctl promote或使用pg_promote()提升备库为主库。原主库停止写入避免双主冲突。将应用连接串切换到新主库。预期结果新主库可正常读写原主库转为备库并重新建立流复制。注意事项切换过程中保持原主库只读防止脑裂切换后立即核对新主库的pg_is_in_recovery()返回false。3. 切换后验证操作执行SELECT pg_is_in_recovery();确认新主库状态。检查新主库的写入与查询是否正常。核对新备库的replay_lag是否持续回落并趋于稳定。预期结果新主库读写正常新备库同步无积压RPO/RTO 达标。注意事项切换后持续观察一段时间确认无隐藏的 IO 或 SQL 瓶颈再恢复全量业务流量。4. 回切流程操作待原主库修复并追平 WAL 后再次执行切换将主库切回原节点。重复切换前检查、切换操作与切换后验证步骤。预期结果主库回到原节点复制状态恢复正常业务无感知。注意事项回切同样需在低峰期进行并完整走一遍验证清单避免二次故障。演练指标对比下表汇总了本次主备切换演练在切换前、切换后及回切后的关键指标便于直观评估演练效果指标切换前切换后回切后复制延迟1.8秒0.9秒1.2秒WAL积压0.3GB0.1GB0.2GBRTO—24分钟26分钟RPO2分钟1分钟1分钟网络RTT9ms8ms9ms说明切换后新主库写入路径更短复制延迟与 WAL 积压进一步下降回切后各项指标恢复至与切换前相当的水平RTO/RPO 均满足目标要求演练整体达到预期效果。5. 结果对比指标异常前恢复后复制延迟32秒1.8秒网络RTT18ms9msWAL积压4.2GB0.3GBRTO31分钟24分钟RPO6分钟2分钟恢复后同步恢复正常抽样核对业务数据一致故障切换演练顺利完成。6. 风险与复盘风险网络抖动和带宽不足会放大复制延迟。WAL持续积压可能导致磁盘空间不足。未定期演练切换流程故障时容易延长恢复时间。复盘建议建立复制延迟告警与趋势分析。定期开展故障注入和切换演练。每次演练记录RTO、RPO、恢复耗时及异常。保持检查清单覆盖网络、WAL、日志、SQL、业务验证等关键环节。本文围绕部署流程、故障注入、指标分析、日志排查、SQL验证及RTO/RPO检查总结了复制延迟突增的标准排查路线。7. 常见问题与排查误区误区一WAL 积压导致磁盘满现象备库回放跟不上主库写入WAL 持续积压最终占满磁盘分区导致数据库写入失败甚至实例异常。解决思路监控pg_wal目录占用与 WAL 生成速率设置磁盘水位告警。优先排查网络带宽、备库 IO 与慢 SQL 等回放瓶颈而非直接清理 WAL。若磁盘确实告急可临时扩容或归档到远端存储但必须同步修复根因避免反复积压。误区二网络抖动误判为备库问题现象复制延迟升高时只盯着备库的 IO 和 SQL忽略主备之间的网络质量导致排查方向错误、恢复时间拉长。解决思路先对比网络 RTT、丢包率与replay_lag的变化趋势确认是否同步恶化。使用ping、mtr或专线监控工具定位链路瓶颈必要时联系网络团队协同处理。网络恢复后再次核对write_lag、flush_lag、replay_lag是否同步回落。误区三备库回放慢的误判现象备库回放慢被简单归因于磁盘 IO实际可能是慢 SQL、索引缺失或回放进程争抢资源所致。解决思路结合备库的 CPU、IO 等待与慢查询日志区分是 IO 瓶颈还是 SQL 效率问题。对高频回放语句做执行计划分析补充必要索引或优化写入模式。通过pg_stat_replication与备库日志交叉验证确认回放延迟的根因后再针对性优化。转载自https://blog.csdn.net/u014727709/article/details/164125298欢迎 点赞✍评论⭐收藏欢迎指正
