PostgreSQL 高可用集群故障分析实战：主节点宕机后未发生自动切换问题排查与解决

摘要

在 PostgreSQL 高可用架构中，自动故障切换（Failover）是保障数据库业务连续性的核心能力。然而在实际生产环境中，经常出现主节点已经故障，但备节点迟迟未提升（Promote）为新的主节点的情况，导致业务长时间中断。

本文结合实际 PostgreSQL + Keepalived + repmgr 集群案例，从故障现象、架构设计、日志分析、故障定位、原因分析、解决方案、预防措施等多个维度深入分析 PostgreSQL 高可用故障切换失效问题。

本文适用于：

• PostgreSQL 主从复制架构

• PostgreSQL + Keepalived

• PostgreSQL + repmgr

• PostgreSQL + VIP高可用

• PostgreSQL HA运维人员

• 数据库管理员(DBA)

一、故障背景

某生产环境部署 PostgreSQL 高可用集群：

集群架构

VIP: 192.168.18.101 | Keepalived | +--------------+--------------+ | | PostgreSQL 主库 PostgreSQL 备库 10.197.167.123 10.197.167.124

服务器配置：

软件版本：

业务通过 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.conf：

failover=automatic

错误配置：

failover=manual

此时：

只告警 不切换

修改：

failover=automatic

重启：

systemctl restart repmgrd

十二、网络脑裂分析

另一种情况：

主库网络断开。

例如：

主库 ↔ 备库 连接中断

主库实际上仍在运行。

备库认为：

主库故障

发生Promote。

结果：

双主

即脑裂。

十三、脑裂危害

例如：

主库写入：

订单10001

备库写入：

订单10002

网络恢复后：

数据冲突

无法自动合并。

造成：数据丢失

• 数据不一致

• 业务故障

十四、VIP为什么没有漂移

分析Keepalived日志：

journalctl -u keepalived

发现：

Script check_pg.sh returned success

说明：

脚本始终返回0

VIP自然不会漂移。

十五、脚本权限问题

常见错误：

-rw-r--r--

没有执行权限。

导致：

Keepalived无法执行脚本

修复

chmod +x check_pg.sh

十六、SELinux影响

Rocky Linux 9：

getenforce

返回：

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

提升成功。

测试三

业务连接VIP：

psql -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 Lag

• WAL生成速率

• Repmgr状态

• Keepalived状态

总结

PostgreSQL 高可用建设并非仅部署主从复制即可完成。真正决定系统可靠性的，是故障检测、自动切换、VIP漂移、脑裂防护以及运维监控体系。

本次案例中，虽然集群已经部署完成，但由于健康检查脚本设计不合理、repmgrd未启动以及自动切换配置错误，导致主库故障后系统未能完成故障转移，最终造成业务中断。

通过完善健康检测逻辑、启用自动故障切换、优化Keepalived配置以及建立标准化故障演练机制，最终实现了PostgreSQL高可用集群在主节点故障情况下10秒内自动恢复业务访问的目标。

对于生产环境而言，建议将故障切换测试纳入日常运维流程，持续验证高可用机制的有效性，确保真正发生故障时系统能够自动、可靠、快速地完成切换，保障业务连续运行。

postgrqsql高可用管理平台推荐：CLup6.x产品手册：CLup简介