MHA 简介
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
OC 简介
orchestrator不仅是一个 MySQL 高可用，更是一款MySQL集群的复制拓扑管理工具，作为服务运行并提供命令行访问、HTTP API 和 Web 界面。OC具备 发现复制拓扑，重构复制拓扑，恢复主库故障等能力。
MHA与OC 对比
| 类目 | 对比项 | MHA | Orchestrator | 总结 |
|---|---|---|---|---|
| 开发语言 | Perl | Go | ||
| 开发组织 | DeNA（youshimaton） | | ||
| 开发目的 | 快速进行主库恢复，以及切换过程中数据补齐 | 进行拓扑结构管理，以及主库故障恢复 | ||
| 部署 | 部署架构 | 只支持单点部署 | 支持多种架构：
| OC部署更为简单 OC服务支持高可用 |
| 数据库服务器是否需要开通SSH免密 | 需要 | 不需要 | ||
| 数据库服务器是否需要Agent | 需要 | 不需要 | ||
| 安装依赖 | 需要安装perl模块 | 不需要，二进制 | ||
| 自身高可用 | 不支持 | 支持 | ||
| 后端数据库 | 不需要 | 需要 | OC 提供多种管理方式， 可管控的集群数量更多 通过Web 界面更容易看清所有集群的状态， 在日常手动切换时可进行拖拽更为方便， | |
| 管理 | 命令行管理 | 支持 | 支持 | |
| HTTP API接口 | 不支持 | 支持 | ||
| Web 界面 | 不支持 | 支持 | ||
| 支持管理集群数量级 | 150+ | 1000+ | ||
| 集中式管理 | 支持 | 支持 | ||
| 新集群使用高可用 | 需要安装依赖，agant ，配置文件，启动进程 | 在数据库集群中创建用户和数据库后进行discovery | 新集群使用高可用OC更加方便 | |
| 复制拓扑发现 | 复制拓扑发现 | 只能发现配置文件中指定的实例 | 通过集群中任何一个实例可以自动发现完整的拓扑 | OC支持的拓扑结构更多， 可动态感知拓扑结构的变化，更加灵活 |
| 自动感知拓扑结构变化 | 不支持 | 支持 | ||
| 支持的复制拓扑结构 |
|
不支持 多于三个主库的环形复制 多源复制 | ||
| 支持的复制模式 | 位点模式(file + postion) GTID模式 基于Row复制(RBR) 半同步复制（Semi-sync） | 位点模式(file + postion) GTID模式（Oracle和MariaDB） 基于statement的复制（SBR） 基于Row复制(RBR) 半同步复制（Semi-sync） 5.7 版本的并行复制 不支持： 5.6版本基于库的并行复制 | ||
| 故障发现 | 故障探活方式 | connect select insert | OC节点 以及 配合该实例的从库复制状态是否正常进行检测 | OC 探活方式更加快速可靠， 能够识别出了主库故障之外其他的故障与警告， 在管理复制拓扑上更胜一筹 |
| 探活间隔 | 默认4次 | 默认1秒 | ||
| 探活次数 | 默认3秒 | 默认1次 | ||
| 探活节点 | 支持多节点探活 | 支持OC节点与从库探活 | ||
| 探活速度 | 9到12秒发现主库故障 | 快 | ||
| 探活理念 | 多次多个节点探活 | 配合从副本的主从状态以及OC节点的探活 | ||
| 探活可靠性 | 较为可靠，无法避免网络抖动带来的影响 | 可靠，采用“整体”方式探活 | ||
| 故障类型 | 主库故障 | 支持接近30多种拓扑结构的故障和警告 根据不同的故障和告警选择不同的处理函数 | ||
| 故障恢复 | 支持的恢复（切换）方式 | 自动恢复 手动切换 |
| OC在故障恢复配置更加灵活，丰富。 OC支持全局开关，特定集群切换开关 多种级别的地域 位置感知 更加丰富即时的实例优先级设置 |
| 设置实例优先级 | 支持设置从库是否可提升为主
| 支持设置多种提升优先级
| ||
| 动态设置实例优先级 | 不支持，需要修改配置文件重启 | 支持，通过修改定时任务 | ||
| 全局切换开关 | 不支持 | 支持 | ||
| 设置集群维护（downtime） | 不支持 | 支持 | ||
| 设置特定集群切换规则 | 不支持 | 支持，通过关键字设别 | ||
| 外挂钩子脚本 |
| OnFailureDetectionProcesses // 故障发现阶段 PreGracefulTakeoverProcesses // 计划内切换流程之前执行，在master设置read_only 之前执行 PreFailoverProcesses // 自动切换流程之前执行 PostMasterFailoverProcesses // 主库切换成功之后 PostIntermediateMasterFailoverProcesses PostFailoverProcesses // 自动切换流程之后执行 PostUnsuccessfulFailoverProcesses // 切换不成功事 PostGracefulTakeoverProcesses // 计划内切换流程之后执行 | ||
| 切换发送通知 | 支持邮件、DC等通知 | 支持邮件、DC等通知 | ||
| 选主规则 | 选择最新的主库 | 选择最合适的主库 | ||
| 位置/地域 感知 | 不支持 | 支持感知多个维度的位置或地域 DataCenter 数据中心 Region 地域 PhysicalEnvironment 位置 | ||
| 防止脑裂 | 配合 shutdown_script | 自定义钩子脚本错误处理，出现错误终止切换 | ||
| 配合公司LVS能力 | 为完成 | 已完成并测试 | ||
| 数据补齐 | 数据补齐 | 配合binlogServer 实现数据无丢失 | 需要配合半同步复制模式防止切换数据丢失 | MHA 对于数据补齐考虑更多，防止在主从切换时数据丢失 |
| 服务器资源利用 | 服务器资源利用 | manage节点可部署在从库，数据库实例尽量不在同一个服务器混合部署 | 可在服务器上进行实例混布，提供资源利用率 |
总结
目前高可用的方案中，MHA（Master High Availability）是使用比较多、并且比较成熟的方案，上图针对一些关键的功能对MHA（Master HighAvailability）和orchestrator进行对比，
MHA（Master High Availability）有一个很大的缺陷是其自身管理节点存在单点问题，而Orchestratort则通过Raft分布式一致性协议保证其自身管理节点的高可用，并且orchestrator相比于MHA（Master High Availability）来说在宕机判断和选主模式上都有比较大的优势，但不足是Orchestrator在某些场景下可能会出现丢数据的情况，数据补偿机制需要进行优化。
Orchestrator还有一些其他高可用方案不具备的优秀功能：
1. 自动发现MySQL复制拓扑，很方便管理多套集群。
2. 支持修改MySQL拓扑结构，变更复制关系。
3. 支持使用命令行工具、Http API、Web界面管理拓扑，如图1-3所示是其Web管理界面。
4. Go语言编写，方便二次开发。
| MHA | OC | ||
|---|---|---|---|
| 部署 | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | OC部署更为简单 OC服务支持高可用 |
| 管理 | ⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | OC 提供多种管理方式， 可管控的集群数量更多 通过Web 界面更容易看清所有集群的状态， 在日常手动切换时可进行拖拽更为方便， |
| 探活 | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | OC 探活理念更加快速可靠 |
| 复制拓扑发现管理 | ⭐️ | ⭐️⭐️⭐️⭐️ | OC 能够识别出了主库故障之外其他的故障与警告， 在管理复制拓扑上更胜一筹 |
| 故障发现 | ⭐️⭐️ | ⭐️⭐️⭐️⭐️ | |
| 故障恢复 | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | OC在故障恢复配置更加灵活，丰富。 OC支持全局开关，特定集群切换开关 多种级别的地域 位置感知 更加丰富即时的实例优先级设置 |
| 数据补偿 | ⭐️⭐️⭐️⭐️⭐️ | ⭐️ | MHA 对于数据补齐考虑更多，防止在主从切换时数据丢失 |
| 恢复速度 | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | MHA 9到12秒故障发现，7-10秒关闭主库服务器防止脑裂，另外需要一些时间去补齐数据，总计10到30秒完成切换。 OC 3-5秒进行故障探测，20秒内进行LVS后端RS切换。30秒内完成故障切换 |
| 资源利用率 | ⭐️⭐️ | ⭐️⭐️⭐️⭐️ | OC结合 LVS可实现数据库实例在服务器上的混布 |
