服务器集群脑裂处理：从现象判断到恢复的完整操作流程

服务器集群脑裂是指集群节点之间失去心跳通信后，各自认为对方已下线，同时争抢同一资源（如虚拟 IP、共享存储挂载点），导致数据损坏或服务异常。
处理核心思路是先判断是否真脑裂，再通过仲裁机制阻止资源双写，最后恢复节点并验证一致性。
以下步骤适用于以 Pacemaker + Corosync 搭建的 Linux 高可用集群，其他集群软件（如 Keepalived、Redis Cluster）思路类似，但命令不同。

判断脑裂现象与定位原因

脑裂的典型表现是同一资源在两个节点上同时启动。
先登录各节点检查资源状态：

pcs status

如果看到 vip 资源在两个节点上都是 Started，基本可以确认脑裂。
接着查看 Corosync 成员状态：

corosync-cmapctl | grep members

输出中每个节点的 ringid 值不一致，说明心跳链路已经分裂。
常见原因包括：交换机故障、网卡异常、防火墙误拦截 UDP 5405 端口、仲裁节点数量不足。
检查防火墙规则：

firewall-cmd --list-all

确认 high-availability 服务已放行。
如果集群只有两个节点且没有仲裁设备，脑裂概率会显著升高，建议增加仲裁节点或配置 two_node: 1 并配合 wait_for_all: 1。

配置仲裁与防双写机制

仲裁的作用是当节点无法互相通信时，由第三方决定哪边继续运行。
Pacemaker 支持多种仲裁方式，最常用的是 fence 设备和 quorum 规则。
先确认 stonith-enabled 是否开启：

pcs property show stonith-enabled

如果返回 false，集群在脑裂时不会自动隔离节点，必须改为 true：

pcs property set stonith-enabled=true

然后配置 fence 设备（以 IPMI 为例）：

pcs stonith create fence_node1 fence_ipmilan \
  ipaddr=192.168.1.101 login=admin passwd=xxx \
  lanplus=1 pcmk_host_list=node1

对每个节点重复创建对应的 fence 设备。
如果没有 IPMI，可以使用 fence_sbd 或云厂商提供的 fence agent。
配置完成后，用以下命令测试隔离是否生效：

pcs stonith fence node1

注意：fence 操作会强制重启节点，生产环境务必在维护窗口执行。

脑裂发生后的恢复操作

确认脑裂后，第一步是停止其中一个节点的集群服务，避免资源继续争抢。
在优先级较低的节点上执行：

pcs cluster stop --all

然后检查另一个节点的资源状态，确认 VIP 和共享存储只挂载在一侧。
如果共享存储出现双写，需要先卸载多余挂载：

umount /dev/sdb1

接着清理失败节点的残留状态：

pcs resource cleanup

等心跳网络恢复后，重新启动被停止的节点：

pcs cluster start --all

观察 pcs status 输出，确认节点重新加入且资源没有再次分裂。
如果资源仍然异常，检查 Corosync 配置文件 /etc/corosync/corosync.conf 中的 bindnetaddr 和 mcastaddr 是否与实际网段一致。

避坑与日常检查要点

不要在有共享存储的集群上直接强制启动两个节点，否则可能造成文件系统损坏。
恢复前先确认存储侧没有双挂载，必要时联系存储管理员。

心跳网络和业务网络必须分开。
如果混用同一张网卡，业务流量高峰可能挤掉心跳包，引发误判。
建议给 Corosync 配置独立网段或 VLAN。

定期检查仲裁状态。
执行 pcs quorum status 可以查看当前是否有法定票数。
如果长期处于 Activity blocked 状态，说明仲裁配置有问题，需要尽快调整。

日志是排查脑裂的第一手资料。
查看 /var/log/cluster/corosync.log 和 journalctl -u pacemaker，重点搜索 membership、quorum lost、fencing 等关键词，能快速定位是网络抖动还是配置错误。

验证恢复效果

恢复后不要只看 pcs status 显示正常就结束。
建议做一次手动切换测试：

pcs resource move vip node2

观察 VIP 是否在 10 秒内漂移到 node2，且原节点资源干净停止。
然后移回：

pcs resource clear vip

最后检查共享存储是否只有一台节点挂载：

mount | grep /dev/sdb1

如果输出只出现在一个节点上，说明防双写机制生效。
建议把上述检查写成定时脚本，每天记录一次仲裁状态和资源分布，便于提前发现隐患。

常见疑问

脑裂后数据一定会丢吗？ 不一定。
如果共享存储有锁机制或数据库自身有防双写保护，数据可能完好。
但文件系统层面的双写通常会导致元数据损坏，恢复后需要做 fsck 检查。

两节点集群能不能不用仲裁设备？ 可以运行，但风险较高。
Corosync 支持 two_node: 1 模式，配合 wait_for_all: 1 能在一定程度上减少误判，但仍建议增加一台轻量仲裁节点或使用云厂商的仲裁服务。

fence 设备配置后需要重启集群吗？ 通常不需要，pcs stonith create 会立即生效。
但建议先用 pcs stonith status 确认设备状态为 Started，再执行实际隔离测试。

脑裂处理的关键在于提前配置好仲裁和隔离机制，而不是等故障发生后再补救。
日常维护中把 pcs status、pcs quorum status 和 fence 测试纳入例行检查，能大幅降低脑裂导致的数据风险。