MHA，即Master High Availability Manager and Tools for MySQL，是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQL Replication（二层）环境，目的在于维持Master主库的高可用性。

一、简介

学习一个高可用小软件，不但要熟悉其功能，还要了解其架构及工作原理。

1. 架构

从架构上来说，MHA分为如下两大部分：

（1） Node

我们知道，MHA是基于MySQL Replication环境的，在该环境中，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。

Node服务器上需要安装MHA Node包。

（2） Manager

Manager为MHA架构中的管理者，建议部署在一台独立的服务器上，当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。

Manager服务器需要安装MHA Manager包，并完善一个主配置文件。

一个Manager可管理多套MySQL Replication环境。

2. 工作原理

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

基本工作流程大致如下：

（1） Manager定期监控Master，监控时间间隔由参数ping_interval决定，缺省为3秒钟一次；可利用其自身的监控功能，也可调用第三方软件来监控；MHA自身提供了两种监控方式：SELECT（执行SELECT 1）和CONNECT（创建连接/断开连接），由于参数ping_type决定，缺省为SELECT方式。

（2） 当监测到Master故障时，调用SSH脚本对所有Node执行一次检查，包括如下几个方面：

??MySQL实例是否可以连接；

??Master服务器是否可以SSH连通；

??检查SQL Thread的状态；

??检查哪些Server死掉了，哪些Server是活动的，以及活动的Slave实例；

??检查Slave实例的配置及复制过滤规则；

??最后退出监控脚本并返回代表特殊意义代码。

（3） 开始Master故障切换，包括如下几个子阶段：

??Phase 1: Configuration Check Phase

在这个阶段，若某个Slave实例的SQL Thread停止了，则会自动启动它；并再次确认活动的Servers及Slaves。

??Phase 2: Dead Master Shutdown Phase

在这个阶段，首先调用master_ip_failover_script，若HA是基于VIP实现的，则关闭VIP，若是基于目录数据库实现的，则修改映射记录。

然后调用shutdown_script脚本强制关闭主机，以避免服务重启时，发生脑裂。

??Phase 3: Master Recovery Phase

又包括如下3个子阶段：

Phase 3.1: Getting Latest Slaves Phase

检查各个Slave，获取最近的和最旧的binary log file和position，并检查各个Slave成为Master的优先级，依赖于candidate_master、no_master、[server_xxx]顺序、binary log差异量等因素。

Phase 3.2: Saving Dead Master's Binlog Phase

若dead master所在服务器依然可以通过SSH连通，则提取dead master的binary log，提取日志的起点就是上一步获取的最新的binary log file和position，直到最后一条事件日志，并在dead master本地的工作目录（由参数remote_workdir决定）中创建文件保存这些提取到的日志，然后将该文件拷贝到Manager服务器的工作目录下（由参数manager_workdir决定）。

当然，若dead master系统就无法连接，也就不存在差异的binary log了。

另外，MHA还要对各个Slave节点进行健康检查，主要是SSH连通性。

Phase 3.3: Determining New Master Phase

接下来调用apply_diff_relay_logs命令恢复Slave的差异日志，这个差异日志指的是各个Slave之间的relay log。

恢复完成后，所有的Slave数据是一致的，此时就可以根据优先级选择New Master了。

Phase 3.3: New Master Diff Log Generation Phase

这里是生成dead master和new master之间的差异日志，即将Phase 3.2保存的binary log拷贝到New Master的工作目录中（remote_workdir）。

Phase 3.4: Master Log Apply Phase

将上一步拷贝的差异日志恢复到New Master上，若发生错误，也可手动恢复。

然后获取New Master的binlog name和position，以便其它Slave从这个新的binlog name和position开始复制。

最后会开启New Master的写权限，即将read_only参数设置为0。

??Phase 4: Slaves Recovery Phase

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase

生成Slave与New Slave之间的差异日志，并将该日志拷贝到各Slave的工作目录下，这部分日志dead master和new master之间差异的那部分日志，因为各个Slave在Phase 3.3阶段已经同步了。

Phase 4.2: Starting Parallel Slave Log Apply Phase

在各个Slave上应用这部分差异日志，然后通过CHANGE MASTER TO命令将这些Slave指向新的New Master，最后开始复制(start slave)。

??Phase 5: New master cleanup phase

清理New Master其实就是重置slave info，即取消原来的Slave信息。

至此整个Master故障切换过程完成。

3. 功能

从官方网站的介绍来看，MHA具有如下几个功能：

（1） Master自动监控和故障转移

基于现有的MySQL主从复制环境，MHA可以监控Master，当发现其故障时，自动进行切换。

在多个Slave环境中，如果个别Slave没有接受到最新的relay log events，MHA则会自动从最新的那个Slave上查找差异的relay log events，并将这些差异事件应用到有延迟的Slave上，最终保持所有的Slave数据一致。通常情况下，MHA可在9-12秒内监测到Master故障，7-10秒内关闭主机以避免脑裂，然后花费几秒时间应用差异的relay log，整个过程通常只需10－30秒即可完成。