虚IP漂移单独使用会加剧脑裂风险，因其仅基于网络层（如ping、进程存活）判断而无视数据库实际状态；若未同步执行SET GLOBAL super_read_only = ON/OFF，旧主可能在VIP切走后仍接受写入，导致双主冲突。
super_read_only 必须开，rpl_semi_sync_master_timeout 不能设成 100ms 或 10s，外部仲裁节点不能只靠 ping 判断存活——脑裂预防不是堆配置，而是让系统在“网络断一半”时仍能拒绝错误决策。
为什么虚IP漂移单独用会加剧脑裂风险
虚IP（VIP）本身不感知数据一致性，只做网络层转发。常见误操作是：脚本检测主库 MySQL 进程存活 + ping 通就漂移 VIP，结果旧主因网络抖动短暂失联后恢复，VIP 却已切到新主，两个节点同时接受写入。
更危险的是，若 VIP 漂移未同步关闭旧主写权限，read_only=ON 形同虚设——拥有 SUPER 权限的用户仍可执行 INSERT/UPDATE。
必须搭配：
- 漂移前调用
SET GLOBAL super_read_only = ON锁死旧主 - 漂移后立即在新主执行
SET GLOBAL super_read_only = OFF - VIP 配置需绑定数据库状态，而非仅操作系统进程
MHA 和 Orchestrator 的仲裁逻辑差异在哪
MHA 依赖中心监控节点 + 自定义 ssh 连通性检查，但自身无法定义“多数派”，一旦监控节点与某从库网络分区，可能误判该从库宕机并触发错误切换。
Orchestrator 内置 Raft，要求至少 (n/2)+1 节点达成共识才允许选主，天然防止单点误判；它还能自动隔离“孤岛节点”（如网络分区后只剩两个节点互通），直接将其标记为 Unreachable 并拒绝参与投票。
关键区别：
- MHA 的仲裁是“监控节点说了算”，Orchestrator 是“集群节点投票决定”
- Orchestrator 支持
raft-enabled配置项开启强一致性，MHA 无此能力 - Orchestrator 故障日志里会出现
Rejecting candidate due to minority quorum类提示，MHA 日志里只有Failover started这类模糊记录
Consul 作为轻量仲裁时最容易漏掉的三件事
Consul 本身不理解 MySQL 状态，它只管 key TTL 是否续租成功。若只用 consul kv put mysql/leader node-a + 定期 consul kv get，以下问题必现：
- 未检查 MySQL 实例是否真在提供服务：节点进程活着、端口通，但
SHOW SLAVE STATUS\G显示Slave_SQL_Running: No，此时续租 leader key 就是灾难 - 未设置合理的 TTL 和续约间隔：TTL 设 30s，但续约脚本每 45s 执行一次，导致合法节点频繁丢权
- 未处理
consul operator raft list-peers返回的status=left节点：这些残留 peer 会干扰 quorum 计算，需手动consul operator raft remove-peer
半同步超时值设为 500–1000ms 的真实依据
这个范围不是拍脑袋定的：rpl_semi_sync_master_timeout 设太低（如 100ms），普通网络抖动（如交换机微秒级拥塞）就会退化为异步复制，等于没开半同步；设太高（如 10s），主库事务卡住 10 秒才返回失败，业务侧早已超时熔断。
500–1000ms 是基于 MySQL 8.0 默认 innodb_flush_log_at_trx_commit=1 下，单次 binlog fsync + 从库落盘的 P99 延迟实测值。
必须配合监控：
- 持续采集
Seconds_Behind_Master和Rpl_semi_sync_master_no_times（退化次数） - 当
Rpl_semi_sync_master_no_times突增，说明超时值不合理或从库 IO 压力过大 - 不要忽略从库的
relay_log_space_limit，空间满会导致 SQL 线程停摆，半同步必然超时
mysql-bin.000001 文件头，确认 SET GLOBAL super_read_only = ON 是否真生效、binlog position 是否被新主完整覆盖。 
