脑裂是什么
主备之间的心跳链路中断后，两侧都认为对方已失效、都认为自己应当接管，于是同时接受写入，数据就此分叉。恢复正常通信后，两份数据无法简单合并，只能人工比对或丢弃一侧的写入。预防靠的是多数派仲裁与隔离机制，而不是更灵敏的心跳。
基本信息
| 成因 | 心跳链路中断，且双方都具备提升条件 |
|---|---|
| 后果 | 双主写入、数据分叉，恢复时难以合并 |
| 预防手段 | 仲裁多数派、隔离动作、人工确认流程 |
| 隔离方式 | 断电、切断网络、吊销存储访问 |
| 设计原则 | 心跳网络与数据网络分离 |
防脑裂的检查思路
防脑裂的检查思路
-- 从库延迟未归零或复制线程异常时，拒绝提升
-- 提升脚本应加入前置检查：延迟、只读状态、日志一致性
SELECT @@global.read_only, @@global.super_read_only;
-- 检查复制状态与延迟
SHOW REPLICA STATUS\G预防机制对照
| 机制 | 作用 | 局限 |
|---|---|---|
| 多数派仲裁 | 少数派无法获得决策权 | 需要奇数节点与独立仲裁链路 |
| 节点隔离 | 强制失联侧无法继续写入 | 隔离手段本身可能失效 |
| 人工确认 | 避免自动提升带来的误判 | 延长恢复时间 |
| 优先级规则 | 约定谁优先接管 | 不能替代隔离动作 |
落地要点
- 心跳与数据走独立网络：同一条链路中断时既无法判定又无法隔离
- 提升动作加前置检查：延迟、只读状态与日志位点都要满足条件才允许切换
- 定期模拟心跳中断：验证仲裁与隔离是否按设计生效，而不是只看配置
- 人工兜底通道要明确：自动切换失败时谁来决定、用什么方式隔离
- 记录切换时间线：事后复盘需要知道每个判定发生在什么时刻
网络抖动时的自动切换要先确认隔离手段：无法隔离故障侧时，宁可人工决策，也不要自动提升备侧。