不会吧？还在用 MHA 做 MySQL 高可用？

Orchestrator 是一款成熟的 MySQL 高可用中间件。采用 Go 语言编写，支持拓扑发现、集群重塑、拓扑恢复等功能。

主要功能

拓扑发现：Orchestrator 主动搜寻并记录 MySQL 节点的主从配置、复制状态等基础信息并进行拓扑映射。即使发生故障，它依然可以提供出色的可视化拓扑图。

集群重塑：Orchestrator 了解复制规则。它能准确识别复制类型：Binlog 位点复制、GTID 复制、伪 GTID 复制、Binlog Server。Orchestrator 还提供了复制检查功能，保证了副本的移动安全可靠。

拓扑恢复：Orchestrator 定义了 30 种故障模型，根据集群拓扑信息可精准识别故障类型。针对不同的故障类型还提供了 15 种恢复执行计划，大大降低了恢复失败的概率。

优势

相较于 MHA 它有以下优势：

• 可视化：Orchestrator 提供了整洁的可视化界面
• 拓扑发现：拓扑自动发现的能力，大大简化了集群管理
• 高可用：Orchestrator 自身基于 Raft 一致性算法实现高可用
• 安全：Orchestrator 强大的审计功能，让我们的每一步操作都有迹可循
• 精准：多达 30 种故障模型，大大降低了误切的可能性
• 高效：Orchestrator 为我们提供了 200+ 的 api 来帮助我们管理 MySQL
• 快速：3s 发现故障 7s 完成切换

高可用

Orchestrator 高可用的实现主要分为两步：

故障检测

函数入口：ContinuousDiscovery --> CheckAndRecover --> GetReplicationAnalysis

故障检测的工作周期为 1 秒，它的主要工作如上图所示：

1. 集群拓扑信息获取：通过 select 语句从后端获取 Binlog 位点、探活是否有效、从库复制情况等集群拓扑信息；
2. 定义故障类型：通过获取到的集群拓扑信息判定故障类型；
3. 探测潜在故障：除了判定故障类型外还会探测集群可能存在的潜在故障。Orchestrator 一共定义了 err1236 在内的 15 种潜在故障类型；

故障恢复

函数入口：ContinuousDiscovery --> CheckAndRecover --> executeCheckAndRecoverFunction

故障恢复的工作周期也是 1 秒，它的主要工作如下：

1. 获取恢复执行计划：Orchestrator 一共定义了 15 种执行计划，根据不同的故障类型它会选择不同的执行计划；
2. leader 节点检查：Orchestrator 集群只有 leader 节点有权限执行恢复操作；
3. 故障注册：对于每一个故障只有注册成功才能执行后续的恢复操作；
4. 全局恢复设置检查：检查是否开启了全局恢复禁止，如果有则中断恢复；
5. 执行步骤 1 中获取的执行计划；
6. 调用 PostUnsuccessfulFailoverProcesses/PostFailoverProcesses 钩子 ；

执行计划

Orchestrator 定义了 15 种执行计划，本次详解故障类型 DeadMaster

故障定义：主节点无法访问，且所有从节点的复制都处于失败状态；

判断标准：1、主节点访问失败；2、从节点访问正常，且所有从节点复制都失败；

DeadMaster 的执行计划为：checkAndRecoverDeadMaster

函数入口：CheckAndRecover --> executeCheckAndRecoverFunction --> checkAndRecoverDeadMaster

详细流程如上图：

1. 注册本次故障恢复；
2. 调用 PreFailoverProcesses Hook ；
3. 获取恢复类型：GTID、伪 GTID、Binlog 位点；
4. 集群重塑：选主、集群拓扑调整；
5. 给故障节点打上维护标签；
6. 切换前地理位置检测：如果我们做了不允许跨 DC 故障转移的设置，本次恢复将中断；
7. 检查新主的复制延时是否超过阀值，如果超过将中断本次恢复；
8. 解析本次恢复，为本次恢复打上成功或者失败的标签；
9. 新主执行：stop slave; 和 reset slave all;
10. 新主执行：set read only false；
11. 尝试旧主执行：set read only true；
12. 在新主执行分离操作：在新主上利用 change master to master_host="//host" ... 命令给 master_host 加上注释标签，防止旧主复活后新主重新挂载。这一步和第 9 步互斥；
13. 替换集群名；
14. 调用 PostMasterFailoverProcesses Hook；

集群重塑

执行计划中最为关键的就是 RegroupReplicasGTID （集群重塑）这一步，接下来我们继续分析 Orchestrator 的集群重塑；

集群重塑一共有三个主要工作：选主、复制检查、结构调整；

选主

• 同 DC、同物理环境检查
• 提升权限检查：must > prefer
• 副本有效性检查：检查副本是否开启 Binlog、检查副本是不是伪副本（ Binlog Server）
• 提升权限被禁止检查：候选副本被禁止参与选主（被禁止包含：PromoteRule 禁止和配置文件中 PromotionIgnoreHostnameFilters 参数禁止）
• 版本检查：版本不低于集群中大多数版本
• Binlog 格式检查：Binlog 格式不小于集群中的最大 binlog 格式（比较规则：ROW>MIX>STATEMENT）

复制检查

主要是执行有效从节点到新主节点的复制可行性检查，具体如下：

• 检查新主是否开启 Binlog 日志；
• 检查新主是否开启 log_slave_updates 参数；
• 从节点和主节点版本比较：从库是否比主库版本小、从库是否是 Binlog server；
• 从库在开启 Binlog 和 log_slave_updates 的情况下检查从库的 Binlog 格式是否低于新主；
• 排除被复制筛选掉的从节点（VerifyReplicationFilters 参数控制开关）；
• 检查 sever id 是否相等；
• 检查 uuid 是否相等且不得为空；
• 检查是否从库 sqldelay < 新主 sqldelay 且主库 sqldelay > ReasonableMaintenanceReplicationLagSeconds 参数；

结构调整

结构调整主要分为三步：

• StopReplication：
• 1、从节点有效性检查；
• 2、执行 stop slave;
• ChangeMasterTo:
• 1、检查从节点 io 线程和 sql 线程是否停止；
• 2、新主 hostname 解析；
• 3、执行 change master to master_host=?, master_port=?;
• StartReplication：执行 start salve;