如何做到MySQL的高可用

0. 引言

数据库宕机 = 业务停摆。高可用的目标不是"永不故障"，而是故障自愈时间足够短、数据丢失足够少。本文建立可用性指标体系，梳理从 MMM/QMHA 到 MGR/InnoDB Cluster 的方案演进，给出故障转移与恢复的标准流程。

1. 可用性指标体系

1.1 SLA 与可用性等级

可用性	年停机时间	俗称
99%（2 个 9）	87.6 小时	一般业务
99.9%	8.76 小时	常规在线业务
99.99%	52.6 分钟	核心业务
99.999%	5.26 分钟	金融/电信级

1.2 MTBF 与 MTTR

MTBF（平均故障间隔）：系统能连续正常运行多久——反映稳定性；
MTTR（平均恢复时间）：故障发生后多久恢复——反映恢复能力；
可用性 ≈ MTBF / (MTBF + MTTR)：降低 MTTR 是性价比最高的路径（MTBF 提升靠硬件/架构投入，MTTR 靠自动化）。

降低 MTTR 的手段：

监控告警前置：主从延迟、复制中断、连接数、磁盘水位 5 分钟内告警；
切换自动化：从"人工改 VIP + 提从库"（分钟级）到"MHA/MGR 自动切换"（秒级）；
预案演练：定期故障演练（拔网线、kill 主库进程、磁盘写满），验证切换脚本；
快速恢复套件：备份可验证（定期恢复演练）、binlog 完整、降级预案（只读兜底）。

2. 避免单点失效

2.1 基础软硬件层

层	措施
电源/网络	双电源、双网卡、跨机柜/跨可用区部署
主机	主备异构（不同物理机/云厂商可用区）
存储	本地 RAID 或分布式存储；备份异地
进程	守护进程（systemd 自动拉起）+ 数据库监控

2.2 共享存储方案

数据库数据放在共享存储（SAN/分布式存储/DRBD 复制盘），主库挂掉后新主库直接挂载同一份数据：

方案	原理	优点	缺点
SAN 共享存储	多机挂载同一存储	切换快、无数据丢失	存储成本高、存储本身成单点
DRBD	块设备实时镜像	成本低	脑裂风险、性能损耗
云盘（ESSD 等）	云厂商分布式存储	高可用托管	绑定云厂商

共享存储方案 RPO≈0（数据在共享盘上），但主备脑裂（split-brain，双主同时写）是最大风险，必须配合 STONITH（隔离故障节点）机制。

3. 高可用方案谱系

3.1 MMM（Multi-Master Replication Manager，历史方案）

双主 + 一台 monitor，通过 VIP 漂移切换；最早的高可用方案之一；
缺陷：依赖虚假 IP、监控脚本复杂、脑裂风险高；新项目已弃用，仅存量系统可见。

3.2 MHA（Master High Availability，经典方案）

图表渲染中…

原理：MHA Manager 监控主库；故障时自动完成"选最新从库 → 补拉缺失 binlog（通过 SSH 从其他从库/主库捞）→ 提升为新主 → 其余从库 re-point"；
优点：成熟稳定、切换秒级、RPO 极小（尽力而为）；
缺点：依赖 SSH 免密、对网络分区敏感、管理面是外部工具（非官方）；
现状：仍广泛用于传统主从架构，但官方推荐逐步迁移到 MGR/InnoDB Cluster。

3.3 Group Replication / InnoDB Cluster（官方现代方案）

图表渲染中…

MGR：组内事务多数派确认才提交（Paxos 类共识），无脑裂（多数派原则天然防 split-brain）；
InnoDB Cluster = MGR + MySQL Shell（部署管理）+ MySQL Router（读写路由/故障感知）；
InnoDB ReplicaSet：无 MGR 的轻量版（传统主从 + Shell 管理），适合不需多写的场景；
切换时间：秒级（Router 感知 Primary 变化自动重路由），RPO=0、RTO≈30s 内；
要求：所有表 InnoDB、有主键、节点间网络稳定（低延迟）、3 节点起步（奇数，容忍 1 节点故障）。

3.4 方案对比

方案	RPO	RTO	脑裂风险	维护方	适用
MMM	低	分钟级	高	社区	❌ 历史遗留
MHA	≈0（尽力）	秒级~10s	中	社区	存量主从
半同步+自研切换	0	秒级	中	自研	定制化需求
MGR/InnoDB Cluster	0	秒级（30s 内）	低（共识）	官方	✅ 新项目首选
云 RDS 高可用	0	秒级	低	云厂商	✅ 上云首选

4. 故障转移与故障恢复

4.1 故障转移（Failover）标准流程

text

1. 监控发现主库不可用（心跳超时/复制中断）
2. 确认故障：排除网络抖动（多次探测 + 仲裁）
3. 隔离故障节点（STONITH/摘除 VIP），防脑裂
4. 选择新主：数据最新（GTID/复制位点对比）优先
5. 提升新主 + 补齐缺失事务（GTID 自动对齐）
6. 其余从库重新指向新主（CHANGE REPLICATION SOURCE）
7. 应用流量切换（Router/VIP/客户端感知）
8. 通知 + 复盘（根因分析、预案修订）

4.2 故障恢复（Failback）

原主库修复后作为从库挂回集群（不要直接夺回主身份——数据可能已落后）；
确认数据追赶完成（GTID 对齐）后再评估是否回切；
回切时机：业务低峰 + 演练过回切流程，避免"切回去又出问题"。

4.3 高可用守护系统

自建高可用（非云）需要一套守护系统：监控（Prometheus + mysqld_exporter）→ 告警（阈值 + 抑制）→ 自动切换（脚本/工具）→ 操作审计（切换记录、演练记录），形成闭环。

5. 故障演练清单

演练项	验证点
kill 主库进程	切换是否自动、RTO 是否达标、数据是否丢失
主从网络隔离	半同步是否降级、切换是否触发
磁盘写满	只读保护是否生效、告警是否及时
从库延迟拉大	延迟告警、读流量是否被剔除
备份恢复	备份可用性（RPO 验证）
DDL 误操作	闪回/binlog 恢复预案

6. 小结

可用性 = MTBF/(MTBF+MTTR)，降 MTTR（自动化切换 + 演练）是核心抓手；
方案演进：MMM（弃用）→ MHA（经典）→ MGR/InnoDB Cluster（官方现代），云上直接用 RDS 高可用；
RPO=0 需要半同步/MGR/共享存储，防脑裂是架构底线（多数派共识或 STONITH）；
故障转移是标准流程：探测→隔离→选主→对齐→切换→复盘，必须演练成肌肉记忆。