【IT老齐245 笔记 + 思考】综合对比九种 MySQL 高可用方案

视频来源B站 IT老齐本文为视频学习笔记 扩展整理覆盖 9 种主流 MySQL 高可用方案的原理、优缺点及选型建议。一、高可用的核心目标目标说明故障自动切换主库挂了从库能自动顶上数据不丢失切换过程中保证数据一致性业务少感知切换时间尽可能短秒级没有完美的方案只有最适合当前阶段的方案。二、九种方案详解1. MMMMulti-Master Replication Manager类型单主原理双主互备 VIP 漂移通过 Agent 监控主库状态故障时自动将 VIP 切换到备主。VIP虚拟IP │ ┌──────┴──────┐ ▼ ▼ ┌────────────┐ ┌────────────┐ │ MasterA │ │ MasterB │ │ (Active) │ │ (Standby) │ └──────┬─────┘ └─────┬──────┘ │ │ ▼ ▼ ┌────────────┐ ┌────────────┐ │ Slave1 │ │ Slave2 │ └────────────┘ └────────────┘维度说明优点自动故障转移、负载均衡、管理工具完善缺点异步复制有数据一致性问题MMM 自身单点VIP 基于 ARP无法跨网段Agent 容易误判频繁切换多年未更新结论已淘汰了解即可2. MHAMaster High Availability类型单主原理由日本 DeNA 公司开发。MHA Manager 持续监控主库故障时自动选择数据最接近原主库的从库提升为新主库并尝试补全差异 binlog。┌─────────────────┐ │ MHA Manager │ ← 监控主库状态 └───────┬─────────┘ │ 心跳检测SSH ▼ ┌───────────┐ ┌──────────┐ ┌──────────┐ │ Master │────▶│ Slave1 │ │ Slave2 │ │(MHA Node) │ │(MHA Node)│ │(MHA Node)│ └───────────┘ └──────────┘ └──────────┘维度说明切换速度0~30 秒最低节点1 Manager 3 数据节点优点成熟稳定、社区广泛使用对 MySQL 侵入小故障切换时尝试补全差异 binlog缺点Manager 是单点挂了就无法自动切换依赖 SSH 稳定性异步复制极端情况丢数据项目更新缓慢适用MySQL 5.6/5.7 时代的主流方案存量系统仍大量使用3. MGRMySQL Group Replication类型单主/多主原理MySQL 5.7.17 引入的官方高可用方案基于Paxos 协议实现组内多节点数据强一致。┌──────────┐ ┌───────────┐ ┌───────────┐ │ Node 1 │◀───▶│ Node 2 │◀───▶│ Node 3 │ │ (Primary)│ │(Secondary)│ │(Secondary)│ └──────────┘ └───────────┘ └───────────┘ ▲ ▲ ▲ └──────────────┴──────────────┘ GCSPaxos 协议两种模式模式说明推荐单主模式只有一个节点可写其余只读推荐多主模式所有节点都可写但冲突检测开销大不推荐维度说明优点MySQL原生功能无需额外工具基于 Paxos 的强一致性保证自动故障检测和主节点选举缺点需要奇数节点最少 3 个写入性能有下降需多数派确认5.7 时期 BUG 多8.0 才成熟对网络稳定性要求高适用MySQL 8.0对数据一致性要求高的核心业务4. MySQL ClusterNDB Cluster类型多主原理基于NDB 存储引擎的分布式方案由三类节点组成数据自动切分并复制到多个数据节点。┌─────────────────────┐ │ Management Node │ ← 管理节点集群配置 └──────────┬──────────┘ │ ┌──────┴──────┐ │ │ ┌───┴────┐ ┌────┴───┐ │ Data │ │ Data │ ← 数据节点NDB 引擎 │ Node 1 │ │ Node 2 │ └───┬────┘ └────┬───┘ │ │ ┌───┴────┐ ┌────┴───┐ │ SQL │ │ SQL │ ← SQL 节点应用连接入口 │ Node 1 │ │ Node 2 │ └────────┘ └────────┘维度说明优点高可用性、支持水平扩展、实时性能好、数据强一致缺点数据全部存内存内存需求极大配置复杂网络要求高不支持 InnoDB只能用 NDB 引擎适用对实时性要求极高、数据量可控的特殊场景如电信计费一般业务不推荐5. Galera Cluster类型多主原理由 Codership 开发的同步多主复制方案使用Galera 插件通过wsrepWrite Set Replication接口实现节点间数据同步。MariaDB 默认集成。┌──────────┐ ┌──────────┐ ┌──────────┐ │ Node 1 │◀═══▶│ Node 2 │◀═══▶│ Node 3 │ │ (Writer) │ │ (Writer) │ │ (Writer) │ └──────────┘ └──────────┘ └──────────┘ 同步复制wsrep / Galera Plugin维度说明优点真正的多主写入同步复制数据强一致任意节点故障集群不受影响对应用透明缺点性能受限于最慢节点“木桶效应”多主写冲突需应用层处理网络延迟敏感只支持 InnoDB适用对数据一致性要求高、写入量不大的场景6. PXCPercona XtraDB Cluster类型多主原理Percona 基于Galera Cluster封装的方案底层同样依赖 Galera 插件实现多主同步复制但提供了更好的工具链和企业级支持。┌──────────┐ ┌──────────┐ ┌──────────┐ │ PXC │◀═══▶│ PXC │◀═══▶│ PXC │ │ Node 1 │ │ Node 2 │ │ Node 3 │ └──────────┘ └──────────┘ └──────────┘ Galera Plugin Percona XtraDB维度说明优点继承 Galera 所有优点Percona 企业级工具链备份、监控社区活跃、文档完善缺点与 Galera 相同写冲突、网络依赖、性能受限于最慢节点与 Galera 区别PXC Galera Percona Server 企业级工具本质是 Galera 的增强发行版7. InnoDB ClusterMGR 的完整方案类型单主/多主原理MySQL 官方的全家桶方案 MGR MySQL Router MySQL Shell提供从部署到运维的一站式体验。┌─────────────────────────────────────┐ │ MySQL Router │ ← 应用层连接入口读写自动路由 └───────────────┬─────────────────────┘ │ ┌───────────────┴─────────────────────┐ │ MGR 集群3节点 │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ Node1│ │ Node2│ │ Node3│ │ │ └──────┘ └──────┘ └──────┘ │ └─────────────────────────────────────┘ │ MySQL Shell 管理维度说明组件MySQL Router中间件代理自动读写分离路由MySQL Shell集群创建、监控、故障恢复MGR底层数据复制优点官方完整方案开箱即用读写自动路由应用无需改代码不依赖第三方工具缺点整套组件较重小团队运维成本高Router 本身需要做高可用适用MySQL 8.0希望用官方全套方案的团队8. Orchestrator类型管理工具配合主从/半同步使用原理Go 语言编写的 MySQL 复制拓扑管理工具自身通过Raft 协议实现多节点高可用部署支持自动故障切换和拓扑重构。┌──────────────────────────────────┐ │ Orchestrator 集群3节点 │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ Oc1 │──│ Oc2 │──│ Oc3 │ │ │ └─────┘ └─────┘ └─────┘ │ │ Raft 协议选举 │ └───────────────┬──────────────────┘ │ 探测 管理 ┌───────┴───────┐ ┌────┴───┐ ┌────┴───┐ │ Master │─────▶│ Slave │ └────────┘ └────────┘维度说明优点自身高可用Raft 选举解决了 MHA Manager 的单点问题Web 可视化界面 API 命令行自动探测和重构复制拓扑缺点部署比 MHA 复杂没有 binlog 补全功能依赖半同步保证一致性需额外维护 Orchestrator 集群使用者GitHub、Booking.com 等适用MySQL 5.7对管理工具高可用有要求的中大型团队9. DRBDDistributed Replicated Block Device类型存储级复制原理Linux 内核模块在块设备层面进行数据复制。将 MySQL 数据目录配置为 DRBD 设备实现主备节点之间数据的实时同步配合 Pacemaker/Heartbeat 实现自动故障切换。┌───────────────┐ ┌───────────────┐ │ Primary │ │ Secondary │ │ ┌───────────┐ │ DRBD │ ┌───────────┐ │ │ │ MySQL │ │ 块复制 │ │ MySQL │ │ │ │ Server │ │◀═══════▶│ │ (Standby) │ │ │ └─────┬─────┘ │ │ └───────────┘ │ │ ┌─────┴─────┐ │ │ ┌───────────┐ │ │ │ DRBD 设备 │ │ │ │ DRBD 设备 │ │ │ └───────────┘ │ │ └───────────┘ │ └───────────────┘ └───────────────┘ ↑ Pacemaker / Heartbeat 管理故障切换维度说明优点在存储层面复制不依赖 MySQL 自身复制机制Linux 内核原生支持成本低数据冗余可靠缺点备节点无法提供读服务纯 Standby故障切换需要 MySQL 启动过程恢复慢对网络带宽要求高需配合 Pacemaker 等工具适用对成本敏感、不需要读写分离的小规模场景三、九种方案综合对比方案类型数据一致性切换速度管理节点 HA运维复杂度最低节点数现状MMM单主一般秒级无中3已淘汰MHA单主较好0~30s无单点中4存量使用MGR单/多主强一致秒级有Paxos较高3主流推荐NDB Cluster多主强一致秒级有高4特殊场景Galera多主强一致秒级有较高3活跃PXC多主强一致秒级有较高3活跃InnoDB Cluster单/多主强一致秒级有高3Router官方推荐Orchestrator管理工具依赖半同步秒级有Raft较高5活跃DRBD存储复制较好较慢需 Pacemaker中2小众四、选型决策树业务场景是什么 │ ├── 个人项目 / 开发测试 │ └── 主从复制 手动切换够了 │ ├── 中小业务成本敏感 │ ├── MySQL 5.7 → MHA │ └── MySQL 8.0 → MGR 单主模式 │ ├── 核心业务数据一致性要求高 │ ├── MySQL 8.0 → MGR / InnoDB Cluster │ └── 需要多主写入 → PXC / Galera注意写冲突 │ ├── 大规模集群需要可视化管理 │ └── Orchestrator 半同步复制 │ ├── 特殊场景电信计费等 │ └── NDB Cluster │ └── 预算极低不需要读扩展 └── DRBD Pacemaker选型核心原则数据安全第一金融、支付等场景选 MGR/PXC 等强一致方案匹配团队能力方案再好团队运维不了也白搭不要过度设计日均几百 QPS 的系统主从就够了考虑升级路径新项目尽量上 MySQL 8.0直接用 MGR五、面试要点面试问题关键回答MySQL 有哪些高可用方案MHA、Orchestrator、MGR/InnoDB Cluster、Galera/PXC、NDB Cluster、DRBDMMM 已淘汰MHA 的最大问题是什么Manager 单点且异步复制可能丢数据MGR 的原理基于 Paxos 协议多数派确认后才提交保证强一致性Galera 和 PXC 什么关系PXC Galera Percona Server 企业级工具是 Galera 的增强发行版NDB Cluster 为什么用得少数据全部存内存成本高只支持 NDB 引擎不支持 InnoDB怎么选型5.7 用 MHA/Orchestrator8.0 推荐 MGR 单主模式需要多主用 PXC半同步和 MGR 的区别半同步只保证至少 1 个从库收到 binlogMGR 保证多数派确认提交多主模式推荐吗一般不推荐冲突检测开销大单主模式更稳定DRBD 适合什么场景预算低、不需要读扩展的小规模场景备机纯 Standby 不提供读服务延伸阅读本文是 099 期的升级版099 期聚焦 6 种方案的深度分析本期补全了 NDB、Galera/PXC、DRBD 三种方案形成完整的九种方案对比。参考资料B站 IT老齐245MySQL高可用九种方案 - 腾讯云美团数据库高可用架构的演进与设想五大常见的MySQL高可用方案 - 博客园