17370845950

主从脑裂可通过外部仲裁（如MHA、Orchestrator、Consul）+ super_read_only强制只读 + 半同步复制（超时500–1000ms）+ 切换后立即锁死旧主来有效预防。

主从脑裂是 MySQL 集群中最危险的故障之一：主库宕机后，多个从库同时被提升为新主库，导致数据写入分裂、不一致甚至丢失。避免脑裂不是靠“多选几个从库”，而是靠明确的仲裁机制 + 严格的故障切换流程 + 持续的状态监控。

用可靠的外部仲裁（如 MHA、Orchestrator 或 Consul）

MySQL 自身不提供跨节点的强一致性选举能力。依赖单个监控节点（比如脚本+VIP）极易因网络分区误判，引发双主。必须引入具备法定票数（quorum）和心跳超时检测的第三方仲裁服务：

• MHA 支持通过 ping 脚本+SSH 连通性组合判断，但需配合自定义 health check 防止假死误切
• Orchestrator 内置 Raft 协议，支持多节点仲裁，自动屏蔽网络隔离的节点
• Consul + 自定义 leader key TTL 可实现轻量级选主，但需确保所有节点能稳定访问 Consul 集群

禁用从库自动写入，强制只读 + super_read_only

即使发生误提升，只要从库处于严格只读状态，就能阻断非法写入。不能只设 read_only=ON，必须开启 super_read_only=ON（MySQL 5.7.8+），否则拥有 SUPER 权限的用户仍可写入：

• 在 my.cnf 中统一配置：read_only=ON 和 super_read_only=ON
• 切换后，新主库需手动关闭 super_read_only；切回前务必重新打开
• 定期检查：SELECT @@read_only, @@super_read_only;，纳入巡检脚本

设置半同步复制 + 合理的 rpl_semi_sync_master_timeout

半同步不是为了提速，而是为故障切换争取“数据安全窗口”。当主库提交事务时，至少一个从库确认接收并落盘，才能返回成功。关键在于超时值设置：

• 超时太短（如 100ms）：网络抖动就退化为异步，失去保护意义
• 超时太长（如 10s）：主库长时间卡住，影响业务可用性
• 建议值：500–1000ms，配合从库 IO/SQL 线程延迟监控，确保多数情况下能及时响应

切断旧主网络或强制只读，杜绝“幽灵主库”复活

脑裂常发生在旧主短暂恢复后继续接受写入。必须在切换完成瞬间执行“断联+锁死”操作：

• 调用运维平台 API 或 Ansible 下发命令，关闭旧主 MySQL 实例或封禁其业务端口
• 若无法停服，立即执行：SET GLOBAL super_read_only = ON; SET GLOBAL read_only = ON;
• 记录旧主 binlog 位置，后续用于比对新主数据是否完整覆盖

不复杂但容易忽略：脑裂预防的核心不在技术堆砌，而在每次故障演练中验证仲裁是否真能拒绝“孤岛节点”的投票请求，以及切换后是否有人真正去检查旧主状态。