高可用性故障如何排查

高可用性（High Availability, HA）系统的故障排查，核心目标是快速定位“为什么不可用 / 为什么切换失败 / 为什么脑裂”，并恢复服务。下面按思路 → 常见故障 → 排查步骤 → 工具 → 实战示例来说明。

一、HA 故障排查总体思路

1. 先确认“是否真的不可用”

   • 是单点不可用，还是整体不可用？
   • 是服务挂了，还是路由/切换错了？

2. 分清故障层级

   • 网络层（断网、延迟、分区）
   • 节点层（宕机、资源耗尽）
   • 服务层（进程崩溃、死锁）
   • 控制层（HA 组件误判、切换失败）

3. 看“状态”而不是“猜测”

   • 当前主节点是谁？
   • 是否发生了切换？
   • 集群是否分裂（split-brain）？

二、常见 HA 故障类型

1. 主节点宕机但未切换

可能原因：

• 心跳中断（网络问题）
• HA agent 挂掉
• 切换脚本失败
• 资源锁未释放

2. 脑裂（Split-brain）

表现：

• 两个节点都认为自己为主
• 数据写入冲突

常见原因：

• 心跳网络单点故障
• 仲裁机制缺失
• fencing 未生效

3. 切换后服务不可用

可能原因：

• VIP 未漂移
• 存储未挂载
• 依赖服务未启动
• 配置文件不一致

4. 频繁切换（flapping）

可能原因：

• 心跳超时设置过短
• 系统负载过高
• 网络抖动

三、通用排查步骤（强烈推荐顺序）

Step 1：确认集群状态

以常见 HA 架构为例：

Pacemaker / Corosync

crm status
pcs status
corosync-cfgtool -s

Keepalived

systemctl status keepalived
ip addr | grep VIP

Kubernetes

kubectl get nodes
kubectl get pods -n <ns>

Step 2：检查心跳 / 网络

ping <peer-ip>
tcpdump -i eth0 port 5405   # corosync

重点看：

• 是否丢包
• 心跳端口是否通
• 是否有网络分区

Step 3：检查资源状态

• VIP 是否在线
• 存储是否挂载
• 服务进程是否运行

ip addr
df -h
ps -ef | grep <service>

Step 4：查看日志（最关键）

/var/log/messages
/var/log/cluster/corosync.log
/var/log/pacemaker.log
journalctl -u keepalived

重点关键词：

• timeout
• fencing
• lost membership
• resource stop failed

Step 5：确认 Fencing / 仲裁

• 是否配置了 STONITH？
• 仲裁节点是否存活？
• 是否允许“少数派存活”？

四、典型场景示例

场景 A：MySQL 主从 + Keepalived，VIP 不漂移

排查：

1. 主库是否真的挂了？
2. Keepalived 是否检测到？
3. 脚本是否返回错误？
4. 防火墙是否拦了 VRRP？

场景 B：Pacemaker 两节点脑裂

原因：

• 无仲裁盘
• 心跳网断

解决：

• 加 QDevice / 第三方仲裁
• 启用 STONITH
• 分离心跳网与管理网

五、预防优于排查（HA 设计建议）

• 心跳网络独立
• 必须 Fencing
• 超时参数保守
• 定期切换演练
• 监控 ≠ HA（Zabbix 不能代替 pacemaker）

如果你愿意，可以告诉我：

• 用的是哪种 HA（Keepalived / Pacemaker / K8s / 云厂商）？
• 故障现象截图或日志

我可以直接帮你“对症下药”。