文章目录
- 每日一句正能量
- 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分钟
关键SQL：
SELECTapplication_name,state,write_lag,flush_lag,replay_lagFROMpg_stat_replication;SELECTnow()-pg_last_xact_replay_timestamp();监控关注：
- WAL生成速率
- replay_lag
- 网络RTT
- 磁盘IO
- CPU利用率
3. 复现过程
故障注入：
- 使用限速工具模拟链路拥塞。
- 持续执行批量写入。
- 观察复制延迟变化。
- 收集数据库日志、系统监控和SQL输出。
时间线显示：网络带宽下降后，WAL发送积压；随后备库磁盘IO升高，回放速度进一步降低。
时间线显示：网络带宽下降后，WAL发送积压；随后备库磁盘IO升高，回放速度进一步降低。
故障排查流程图
基于上述复现过程，可梳理出如下标准排查流程：
流程说明：告警触发后先确认复制状态与延迟指标，再按“网络 → 备库IO → WAL”的顺序逐层排查，定位根因后恢复并验证同步，最终确认数据一致性与RPO/RTO达标。
4. 方案实施
部署/演练流程：
- 检查复制状态。
- 核对WAL是否连续。
- 排查网络带宽与RTT。
- 检查备库IO及慢SQL影响。
- 恢复网络并重新验证同步。
验证SQL：
SELECTpg_is_in_recovery();SELECTnow()-pg_last_xact_replay_timestamp();检查清单：
- WAL发送正常
- replay_lag恢复
- 网络稳定
- 数据一致性通过
- 切换演练通过
主备切换演练
1. 切换前检查
操作：
- 确认主库与备库复制状态正常，
replay_lag处于可接受范围。 - 核对 WAL 归档是否连续，备库已接收并回放最新 WAL。
- 检查主备网络 RTT 与带宽，确认链路稳定。
- 确认业务低峰期窗口，并提前通知相关方。
预期结果：主备数据一致，pg_stat_replication显示state=streaming，replay_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.3GB | 0.1GB | 0.2GB |
| RTO | — | 24分钟 | 26分钟 |
| RPO | 2分钟 | 1分钟 | 1分钟 |
| 网络RTT | 9ms | 8ms | 9ms |
说明：切换后新主库写入路径更短，复制延迟与 WAL 积压进一步下降；回切后各项指标恢复至与切换前相当的水平，RTO/RPO 均满足目标要求，演练整体达到预期效果。
5. 结果对比
| 指标 | 异常前 | 恢复后 |
|---|---|---|
| 复制延迟 | 32秒 | 1.8秒 |
| 网络RTT | 18ms | 9ms |
| WAL积压 | 4.2GB | 0.3GB |
| RTO | 31分钟 | 24分钟 |
| RPO | 6分钟 | 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
欢迎 👍点赞✍评论⭐收藏，欢迎指正
