摘要在 PostgreSQL 高可用架构中自动故障切换Failover是保障数据库业务连续性的核心能力。然而在实际生产环境中经常出现主节点已经故障但备节点迟迟未提升Promote为新的主节点的情况导致业务长时间中断。本文结合实际 PostgreSQL Keepalived repmgr 集群案例从故障现象、架构设计、日志分析、故障定位、原因分析、解决方案、预防措施等多个维度深入分析 PostgreSQL 高可用故障切换失效问题。本文适用于PostgreSQL 主从复制架构PostgreSQL KeepalivedPostgreSQL repmgrPostgreSQL VIP高可用PostgreSQL HA运维人员数据库管理员(DBA)一、故障背景某生产环境部署 PostgreSQL 高可用集群集群架构VIP: 192.168.18.101 | Keepalived | ---------------------------- | | PostgreSQL 主库 PostgreSQL 备库 10.197.167.123 10.197.167.124服务器配置节点IP角色node110.197.167.123Primarynode210.197.167.124StandbyVIP192.168.18.101业务访问地址软件版本软件版本PostgreSQL16repmgr5.xKeepalived2.xRocky Linux9业务通过 VIP 访问数据库。二、故障现象某日主节点发生异常systemctl stop postgresql或者kill -9 postgres主库已经停止。理论上应该发生主库故障 ↓ Keepalived检测失败 ↓ VIP漂移 ↓ 备库Promote ↓ 业务恢复但实际情况主库停止 ↓ VIP未漂移 ↓ 备库未提升 ↓ 业务中断故障持续超过30分钟。三、故障现场分析3.1 查看VIP主库ip a发现192.168.18.101 依然存在说明Keepalived未降级VIP没有释放。3.2 查看Keepalived状态systemctl status keepalived结果active (running)Keepalived服务正常。但VIP未漂移。说明健康检查失效四、检查健康检测脚本配置vrrp_script chk_pgsql { script /etc/keepalived/check_pg.sh interval 2 weight -20 }查看脚本cat check_pg.sh内容ps -ef | grep postgres存在严重问题。五、错误脚本分析假设 PostgreSQL 已停止ps -ef | grep postgres返回postgres 12345 grep postgres脚本判断if ps -ef | grep postgres then exit 0 fi结果误判存活Keepalived认为PostgreSQL正常不会触发切换。六、正确检测方式推荐pg_isready示例pg_isready -h 127.0.0.1 -p 5432正常accepting connections异常no response脚本#!/bin/bash pg_isready \ -h 127.0.0.1 \ -p 5432 \ -U postgres if [ $? -eq 0 ] then exit 0 else exit 1 fi七、第二类故障数据库进程存在但服务不可用最常见问题Postgres进程存在 但无法连接例如ps -ef | grep postgres显示postgres running但psql连接失败。原因WAL阻塞IO故障死锁磁盘满此时进程检测失效必须采用psql -c select 1检测。八、repmgr状态检查查看repmgr cluster show正常ID | Name | Role 1 | node1 | primary 2 | node2 | standby故障后node1 unreachable node2 standby发现node2没有自动提升九、检查repmgrd服务查看systemctl status repmgrd结果inactive问题找到。repmgr虽然安装repmgrd未启动因此无法自动故障切换十、启动自动切换服务systemctl enable repmgrd systemctl start repmgrd验证repmgr service status结果running十一、检查自动提升配置repmgr.conffailoverautomatic错误配置failovermanual此时只告警 不切换修改failoverautomatic重启systemctl restart repmgrd十二、网络脑裂分析另一种情况主库网络断开。例如主库 ↔ 备库 连接中断主库实际上仍在运行。备库认为主库故障发生Promote。结果双主即脑裂。十三、脑裂危害例如主库写入订单10001备库写入订单10002网络恢复后数据冲突无法自动合并。造成数据丢失数据不一致业务故障十四、VIP为什么没有漂移分析Keepalived日志journalctl -u keepalived发现Script check_pg.sh returned success说明脚本始终返回0VIP自然不会漂移。十五、脚本权限问题常见错误-rw-r--r--没有执行权限。导致Keepalived无法执行脚本修复chmod x check_pg.sh十六、SELinux影响Rocky Linux 9getenforce返回Enforcing可能拦截脚本执行。查看ausearch -m avc临时关闭测试。十七、sudo权限问题很多脚本包含sudo systemctl stop keepalived但keepalived用户无sudo权限导致脚本失败。配置visudo加入postgres ALL(ALL) NOPASSWD:ALL十八、WAL配置问题检查show wal_level;应为replica检查show max_wal_senders;建议10检查show wal_log_hints;应on否则十九、复制状态检查主库select * from pg_stat_replication;正常state streaming异常0 rows说明复制中断二十、备库状态检查select pg_is_in_recovery();结果t表示备库Promote后f表示主库二十一、故障恢复测试测试流程测试一关闭主库systemctl stop postgresql结果VIP漂移成功测试二查看备库select pg_is_in_recovery();结果false提升成功。测试三业务连接VIPpsql -h 192.168.18.101连接正常。二十二、最终解决方案经过排查发现根本原因1. Keepalived检测脚本误判 2. repmgrd未启动 3. failover配置错误修复优化健康检查 启用repmgrd 开启automatic failover 增加VIP检测 增加日志监控最终实现主库故障 ↓ 2秒检测 ↓ VIP漂移 ↓ 备库Promote ↓ 业务恢复恢复时间小于10秒满足生产要求。二十三、最佳实践建议建议一不要使用ps -ef | grep postgres作为唯一检测依据。建议二优先使用pg_isready和select 1组合检测。建议三启用repmgrd自动切换。建议四定期进行故障演练。建议每月一次Failover测试。建议五监控以下关键指标PostgreSQL状态VIP归属Replication LagWAL生成速率Repmgr状态Keepalived状态总结PostgreSQL 高可用建设并非仅部署主从复制即可完成。真正决定系统可靠性的是故障检测、自动切换、VIP漂移、脑裂防护以及运维监控体系。本次案例中虽然集群已经部署完成但由于健康检查脚本设计不合理、repmgrd未启动以及自动切换配置错误导致主库故障后系统未能完成故障转移最终造成业务中断。通过完善健康检测逻辑、启用自动故障切换、优化Keepalived配置以及建立标准化故障演练机制最终实现了PostgreSQL高可用集群在主节点故障情况下10秒内自动恢复业务访问的目标。对于生产环境而言建议将故障切换测试纳入日常运维流程持续验证高可用机制的有效性确保真正发生故障时系统能够自动、可靠、快速地完成切换保障业务连续运行。postgrqsql高可用管理平台推荐CLup6.x产品手册CLup简介
建模、控制与自感知技术全解析)
