MHA简介：
MHA是由日本人yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台mysql服务器上，MHA Manager会定时探测集群中的master节点，当master出故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其它的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
MHA基本机构图如下：
以上拓扑图展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结如下：
（1）从宕机崩溃的master服务器中保存二进制日志事件（binlog events）
（2）识别含有最新更新的slave
（3）应用差异的中继日志（relay-log）到其它slave
（4）应用从master保存的二进制日志事件（binlog events）
（5）提升一个新的slave为master
（6）使其它的slave连接新的master进行复制。
一、部署环境
大概部署环境如下：（说明：所有系统均为centos7.3，其中server03、server04为server02的从）
| 角色 | ip | 主机名 | 类型 |
| 监测主机（monitor host） | 172.17.5.1 | server01 |
监控复制组 |
| 主服务器（master） | 172.17.5.2 | server02 | 写入 |
| 备用主服务器（candicate master） |
172.17.5.3 | server03 | 读 |
| 从服务器（slave） | 172.17.5.4 | server04 | 读 |
二、配置hosts本地解析
①四台机器配置相同的hosts解析。（也可以在mysql配置文件里配置忽略名字解析skip-name-resolve）
三、配置四台主机之间ssh免密登陆（都需要配置哦）。
四、配置mysql服务。
①在master（server02）主机上配置mysql主配置文件
②在其它三个服务器上配置mysql主配置文件（注意：server-id不一样，其它配置文件都一样）。
③配置好主从节点之后，按MYSQL复制配置架构的配置方式将其配置完成并启动master节点和各slave节点，以及为各slave节点启动其IO和SQL线程，确保主从复制运行无误。操作如下：
在master（server02）服务器上授权slave服务器能连接数据库读取二进制日志事物。
在其它机器上获取master的权限，开启复制功能。（三台机器一样）
五、搭建MHA环境和配置服务。
①在master（server02）服务器上创建MHA管理复制的账号。
②在所有服务器上安装mha4mysql-node（我是下载好安装包使用rpm安装的）
③在监测主机（monitor host）上安装mha4mysql-manager
④定义MHA管理配置文件。
在manager（server01）配置：
定义一个统一管理的用户和目录，方便以后管理。
mkdir -p /etc/mha_master/app1
修改MHA配置文件如下：
⑤在master（server02）和slave（server03、04）创建工作目录
命令：mkdir /mydata/mha_master/app1
⑥检测各节点之间ssh通讯是否ok（server01执行）
⑦再次在master（server02）执行mysql授权sql语句。【为了确保各slave服务器节点正常，随时可以成为master服务器】
⑧masterha_check_repl工具检查mysql主从复制是否成功
⑨启动MHA
五、测试。
①停止master（server02）服务器，查看manager（server01）日志。
systemctl stop mariadb (sserver02)
②查看备用slave是否为master了。
③恢复master（server02）。
六、日常操作
①校验ssh等效验证
$ masterha_check_ssh --conf=/etc/masterha/app1.cnf
②校验mysql复制
$ masterha_check_repl --conf=/etc/masterha/app1.cnf
③启动mha监控，在master故障时开启自动转移
$ nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log < /dev/null 2>&1 &
###当有slave节点宕掉的情况是启动不了的，加上--ignore_fail_on_start即使有节点宕掉也能启动mha
$ nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_fail_on_start > /tmp/mha_manager.log < /dev/null 2>&1 &
④检查启动的状态
$ masterha_check_status --conf=/etc/masterha/app1.cnf
⑤停止mha
$ masterha_stop --conf=/etc/masterha/app1.cnf
⑥多次failover
MHA在每次failover切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候如果由于间隔时间太短导致切换不成功，应手动清理掉。
rm -rf /var/log/masterha/app1/app1.failover.complete或者通过加上参数--ignore_last_failover来忽略
⑦手工failover
手工failover场景，适用于在master死掉，而masterha_manager未开启情形，如下，指定--master_state=dead
masterha_master_switch --conf=/etc/masterha/app1.cnf --dead_master_host=192.168.1.6 --master_state=dead --new_master_host=192.168.1.7 --ignore_last_failover
⑧手动在线切换,如下，指定--master_state=alive
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave --running_updates_limit=10000 --orig_master_is_new_slave
表明在切换时原master变为新master的slave节点
--running_updates_limit=10000
切换时候选master如果有延迟的话，mha切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover时relay日志的大小决定