故障转移
问题
数据库主从架构中，主库宕机后如何自动切换到从库？如何防止脑裂？MHA 和 Orchestrator 怎么选？
答案
故障转移流程
MHA（Master High Availability）
MHA 是最经典的 MySQL 高可用方案：
切换过程：
- MHA Manager 检测到 Master 不可用
- 登录 Master 尝试保存 binlog（如果还能访问）
- 选择 relay log 最新的 Slave 为新 Master
- 将差异 binlog 应用到新 Master
- 其他 Slave 切换到新 Master
- 通知应用/VIP 漂移
MHA 的局限：
- Manager 是单点（需要额外做 HA）
- 一次性工具，切换后 Manager 进程退出
- 不支持多机房
Orchestrator
GitHub 开源的 MySQL 高可用工具，比 MHA 功能更强大：
| 特性 | MHA | Orchestrator |
|---|---|---|
| 拓扑管理 | 无 | Web UI 可视化 |
| 故障检测 | 心跳检测 | 多路径检测 |
| 切换模式 | 自动 | 自动 + 手动 |
| 持续运行 | 切换后退出 | 持续运行 |
| GTID 支持 | 有限 | 完善 |
脑裂问题
脑裂（Split Brain）：网络分区导致两个节点同时认为自己是主库，都接受写入。
防脑裂措施：
| 措施 | 说明 |
|---|---|
| VIP 漂移 | 只有持有 VIP 的节点才接受写入 |
| Fencing（隔离旧主） | 切换前先关闭旧主（STONITH: Shoot The Other Node In The Head） |
| 设置 read_only | 旧主降级为只读 |
| 网络隔离 | iptables 禁止旧主接收写流量 |
| 超半数选举 | MGR/Raft 等协议天然防脑裂 |
故障转移策略
| 策略 | 说明 | RPO | RTO |
|---|---|---|---|
| 自动切换 | MHA/Orchestrator 自动执行 | 接近 0 | 10-30s |
| 手动切换 | DBA 人工决策执行 | 0 | 分钟级 |
| DNS 切换 | 修改 DNS 指向新主 | 接近 0 | 取决于 TTL |
| VIP 漂移 | Keepalived VIP 飘移 | 接近 0 | 秒级 |
RPO 和 RTO
- RPO（Recovery Point Objective）：可容忍的数据丢失量
- RTO（Recovery Time Objective）：故障恢复时间
常见面试问题
Q1: MySQL 主库宕机后怎么处理？
答案：
- 检测故障：MHA/Orchestrator 通过心跳检测主库不可用
- 选择新主：选择数据最新的从库（relay log 最完整或 GTID 最大）
- 数据补全：将其他从库缺少的事务同步过来
- 提升新主：
STOP SLAVE; RESET SLAVE ALL; - 切换从库：其他从库
CHANGE MASTER TO指向新主 - 切流量：VIP/DNS 指向新主
- 修复旧主：恢复后作为从库加入集群
Q2: 如何判断应该提升哪个从库？
答案：
选主优先级：
- GTID 最新：数据最完整的从库
- 候选配置：人为指定的候选主库（硬件配置好）
- 同机房：优先选同机房的从库（减少延迟）
- 排除黑名单：排除延迟大、配置低的从库
Q3: 如何防止脑裂？
答案：
- Fencing：切换前强制关闭旧主（IPMI 远程关机、iptables 禁写）
- VIP 互斥：确保同一时刻只有一个节点持有 VIP
- 半同步复制：只有确认从库收到数据后才提交
- MGR/Raft：多数派协议天然防脑裂