MHA 与 Orchestrator 是什么
两者都是 MySQL 主从架构的高可用工具。MHA 是较早的方案，由管理节点探测主库并在故障时把最接近的从库提升为新主，配置文件驱动、脚本化程度高，但项目已多年停止活跃维护。Orchestrator 走的是「拓扑管理 + 切换」路线：持续探测整个复制拓扑，提供 Web 界面与 HTTP API，支持自动或手动切换，社区仍在维护。选型时真正决定成败的不是工具，而是切换流程是否演练过、有无防脑裂手段。
基本信息
| 适用版本 | MySQL 5.7 / 8.0 主从、级联复制拓扑 |
|---|---|
| MHA 组件 | manager 节点（探测与切换）+ node 工具（各数据节点） |
| Orchestrator 组件 | orchestrator 服务 + backend 存储（MySQL 或 SQLite）+ 客户端/API |
| 探测方式 | MHA 周期探活；Orchestrator 持续拓扑发现与故障检测 |
| 切换方式 | MHA 脚本驱动；Orchestrator 支持自动与手动、可挂钩子 |
| 共同前提 | 旧主必须能被隔离，否则双写脑裂 |
典型使用场景
- 存量主从架构的主库故障自动切换
- 拓扑可视化与资产管理：一眼看到主从关系与延迟
- 计划内切换（switchover）：发版或迁移时把主库平滑换到目标节点
- 故障演练：模拟主库宕机，验证切换流程与耗时
- 与中间件配合：切换后由代理层把流量指向新主
两者对比
| 维度 | MHA | Orchestrator |
|---|---|---|
| 定位 | 专注主从故障切换 | 拓扑管理 + 切换 |
| 维护状态 | 已停止活跃维护 | 社区活跃 |
| 驱动方式 | 配置文件与脚本驱动 | API / 钩子驱动，可接发布系统 |
| 拓扑能力 | 以主库为中心 | 全拓扑发现，支持级联与多集群 |
| 适用场景 | 存量老架构过渡期 | 新架构与云上混合部署 |
| 上手成本 | 依赖既有脚本资产 | 需先搭服务与后端存储 |
选型与落地提示
选型与落地提示
# 新项目：优先考虑 MySQL 原生 MGR，或 Orchestrator 做拓扑管理
# 存量 MHA：评估迁移成本，至少保证切换预案人工可执行
# 无论用哪个工具，先补齐三件事：
# 1) 故障判定标准（几路探测、多久确认）
# 2) 旧主隔离手段（fencing：断电、剥网、只读锁定）
# 3) 切换后的验证点（写入自测、应用探针恢复）切换工具只解决「谁是新主」，不解决「流量怎么切」：应用连接串、VIP、代理层配置都要能在分钟内跟着切换，否则会出现主库已经提升、业务仍在连旧地址的情况。
自动切换必须配合防脑裂（fencing）：旧主网络分区恢复后若仍可写，就会出现两个可写主库，数据冲突后需要人工比对修复，代价远高于一次手动切换。