MySQL 高可用演进：从 MHA 到 Orchestrator 的切换与恢复实践

MySQL 高可用方案的选择是数据库架构的核心决策之一。方案从早期的 MHA（MySQL Master High Availability）演进到 Orchestrator + 半同步复制，再到官方的组复制（Group Replication）和 InnoDB Cluster。每种方案在切换速度、数据一致性保证、部署复杂度和运维成本上都有不同的权衡。

MHA 是最早被广泛使用的 MySQL 高可用工具。它的原理是在主库故障时，从多个从库中选出数据最新的一个提升为新主库，并尝试从旧主库补齐未复制的 binlog。MHA 的优点是成熟稳定、社区文档丰富；缺点是切换速度慢（通常 10-30 秒）、已停止社区维护、不支持自动拓扑发现。对于已有 MHA 的系统，建议规划向 Orchestrator 或组复制迁移；对于新项目，不建议再选 MHA。

Orchestrator 是目前 MySQL 高可用的主流方案。它是一个 MySQL 高可用和复制拓扑管理工具，支持自动故障检测、自动或手动切换、拓扑可视化、钩子脚本。配合半同步复制（semi-sync），可以在切换时保证数据一致性。Orchestrator 的优点是切换速度快（秒级）、拓扑可视、社区活跃；缺点是配置较复杂、需要理解其钩子机制。

MySQL Group Replication 是官方提供的高可用方案，基于 Paxos 协议实现多主同步复制。优点是原生支持、数据强一致、自动成员管理；缺点是要求 MySQL 8.0+、写性能受限于组内最慢节点、网络延迟敏感。InnoDB Cluster 是 Group Replication + MySQL Router + MySQL Shell 的完整封装，适合新项目从头搭建。

高可用切换不只是"把从库提升为主库"。完整的切换流程包括：故障检测、切换决策、新主提升、应用连接恢复（通过 VIP/DNS/Proxy）、旧主恢复（如果可恢复）、延迟数据补齐、事后复盘。很多团队只关注切换本身，忽略了应用连接恢复和事后数据补齐，导致切换后出现数据不一致。

盈尺在金融、央企的 MySQL 运维中，通常推荐 Orchestrator + 半同步复制作为主力方案，新项目考虑 InnoDB Cluster。基于 DMP 平台可以管理 MySQL 的主从、MHA 切换、快照等操作，但高可用架构选型需要结合业务一致性要求和团队运维能力。