MySQL实战：高可用架构

MHA (Master High Availability)

MHA 是一种比较传统的、基于 Perl 脚本开发的外部自动化运维管理工具。它不改变 MySQL 原生的主从复制架构，而是在上方作为一个“监控和调度者”

执行流程

第一步：多方验证，确诊故障 Manager 连不上主库时，会让从库也确认一下。大家都反馈连不上，才确诊主库宕机。这能有效避免因监控节点自身网络问题导致的误切换和脑裂

第二步：尽力恢复，拷贝日志 确诊后，Manager 会尝试通过 SSH 登录主库磁盘，把还没传出去的 Binlog（二进制日志）强行拷贝出来，补发给从库

如果主库彻底断电、SSH 连不上，Manager 会果断放弃拷贝，直接以当前数据最最新（Relay Log 最多）的从库为基准进行切换。(注：此时若结合半同步复制，仍可保证数据不丢)。

第三步：对齐差异，挑出新主 在剩下的从库中选出一个作为新主。MHA 会自动计算其他从库与新主的数据差异，让它们把差异的日志补齐，确保整个集群存活节点的数据完全一致。

第四步：VIP漂移，业务恢复 触发外部脚本，把 VIP（虚拟 IP）从老主库解绑，漂移并绑定到新主库上。同时命令其他从库 CHANGE MASTER TO 指向新主。前端应用闪断重连，10~30秒内业务完全恢复

Orchestrator + Consul/ProxySQL

Orchestrator 是 GitHub 开源的、目前业界使用非常广泛的 MySQL 拓扑管理与高可用工具。它通常配合 Consul（服务发现/KV存储） 或 ProxySQL（中间件） 来实现流量的自动切换

正常运行：Orchestrator 通过定期嗅探获取整个 MySQL 的集群拓扑结构。流量通过 ProxySQL 进行读写分离和路由

故障发现：Orchestrator 通过特殊的算法（不仅仅是简单的 Ping，还会参考下游 Slave 的报错状态）来确诊 Master 真的故障了，防止脑裂和误判

恢复拓扑：Orchestrator 自动将表现最好的 Slave 提升为新主，并利用 GTID（全局事务ID）技术，一键将其他 Slave 挂载到新主下方，瞬间重构拓扑

流量切换：Orchestrator 触发 Hook 脚本，更新 Consul 中的键值，或者直接调用 API 修改 ProxySQL 的后端路由规则，将写流量导向新主

MGR (MySQL Group Replication)

MGR 是 MySQL 5.7.17+ 官方原生的、基于 Paxos 一致性协议 的高可用插件。通常推荐使用“单主模式（Single-Master）”

执行流程

数据同步（事务原子广播）：

1. 当 Primary 节点收到一个写事务时，在提交（Commit）前，会把该事务的变更（Write Set）广播给集群内的所有节点
2. 节点之间通过 Paxos 协议 进行投票共识。只要超过半数（$N/2 + 1$）的节点同意，该事务就可以进入认证（Certification）阶段
3. 认证通过后，Primary 节点本地提交，Secondary 节点异步回放（Applier）对应的 Relay Log

故障发现：MGR 内部有内建的分布式心跳检测机制。如果 Primary 故障，其他节点在设定的超时时间内未收到其心跳，会将 Primary 踢出集群（Group）

自动选主：剩下的 Secondary 节点会自动进行选举。选举依据是：各个节点的 MySQL 版本（低版本优先）、member_weight 权重，以及事务应用进度（GTID 最大的优先）

状态切换：当新的 Primary 被选出后，它会自动切换为 Read/Write 状态，其余节点保持 Read Only。对外配合 MySQL Router 可以实现透明的流量切换

总结

方案名称	数据一致性	故障切换速度	架构复杂度	核心依赖	适用场景
MHA	较好（依赖半同步）	10s ~ 30s	中等	Perl脚本、SSH免密	中小型企业、传统一主多从架构
Orchestrator	极好 (强制要求GTID)	秒级 (3s~10s)	较高	Go、Consul/ProxySQL	大型互联网公司、大规模MySQL集群管理
MGR	完美 (强一致性)	秒级 (<5s)	低 (原生内置)	MySQL 5.7+/8.0、InnoDB	对数据安全性要求极高（如金融、交易）的业务