上一篇介绍了MySQL的主从复制、读写分离，实现主从服务器同步的架构，它存在单点故障的隐患，一旦主服务器出现故障，将无法进行写入，为了解决这个问题，可以考虑是否能够让从服务器切换角色，自动变为主服务器，继续提供服务呢？答案当然是可行的，这里就必须要用到MHA架构了。
MHA是一套优秀的MySQL高可用环境下故障切换和主从复制的软件；MySQL故障过程中，MHA能做到0-30秒内自动完成故障切换。
它由两部分组成，MHA Manager (管理节点）和 MHA Node（数据节点）
- MHA Manager 可以单独部署在一台独立的机器上，管理多个 master-slave 集群（Manger是单独一台监控master服务器健康状态的服务器。）；也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点。当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。
MHA的特点：
- 自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失
- 使用半同步复制，可以大大降低数据丢失的风险
- 目前MHA支持一主多从架构，最少三台服务器，即一主两从，一台为主备，也可以两台从的都做主备
综上所述，我们至少需要四台主机，三台做主从复制（一主两从，两从中一台为主备，即主服务器宕机，这台主备成为新的主服务器），一台作为manager，检测管理数据库集群。通过监控 MySQL 数据库，在故障时进行自动切换，不影响业务。
整体思路
1） 安装 MySQL 数据库
2） 配置 MySQL 一主两从
3） 安装 MHA 软件
4） 配置无密码认证，ssh免密登录
5） 配置 MySQL MHA 高可用
6） 模拟 master 故障切换
环境介绍
- 服务器 CentOS7.3(64 位) MHA-manager/192.168.247.160
管理节点，安装 manager 组件 - 服务器 CentOS7.3(64 位) Mysql1/192.168.247.130 Master 节点，安装 node 组件
- 服务器 CentOS7.3(64 位) Mysql2/192.168.247.140 Slave 节点，安装 node 组件
- 服务器 CentOS7.3(64 位) Mysql3/192.168.247.150 Slave 节点，安装 node 组件
下面只在 Mysql1 上面做演示，安装过程如下。
2.1.1 安装编译依赖的环境
2.1.2 安装 gmake 编译软件
2.1.3 安装 MySQL 数据库
2.2.1 修改主配置文件/etc/my.cnf 文件，三台服务器的 server-id 不能一样，另外两台写 2 和 3 即可！写入内容如下：
Mysql1：master
Mysql2：slave1
Mysql2：slave2
2.2.2 Mysql1、Mysql2、Mysql3 分别做两个软链接，软链接是为 MHA服务的。
2.2.3 Mysql1、Mysql2、Mysql3 启动 MySQL。**
2.2.4 数据库的授权操作
在所有数据库节点上授权两个用户，一个是从库同步使用，另外一个是 manager 使用。
下面三条授权按理论是不用添加的，但是做案例实验环境时候通过 MHA 检查MySQL 主从有报错，报两个从库通过主机名连接不上主库，所以所有数据库加上下面的授权。（在/etc/hosts里做映射也可解决）
2.2.5 从数据库实现同步
在 Mysql1 主机上查看二进制文件和同步点，
接下来在 Mysql2 和 Mysql3 分别执行同步。
查看两个从数据库， IO 和 SQL 线程都是 yes 代表同步是否正常。
必须设置两个从库为只读模式：
在 Mysql1 主库插入两条数据，测试是否同步。到这里主从复制就完成了。
2.3.1 所有服务器上都安装 MHA 依赖的环境，首先安装 epel 源。
2.3.2 安装node组件
MHA 软件包对于每个操作系统版本不一样，这里 CentOS7.3 必须选择 0.57 版本，
在所有服务器（四台主机）上必须先安装 node 组件，因为 manager 依赖 node 组件，
下面都是在 Mysql1 上操作演示安装 node 组件。
2.3.3 安装manager组件
在 MHA-manager 上安装 manager 组件
manager 安装后在/usr/local/bin 下面会生成几个工具，主要包括以下几个：
masterha_check_ssh //检查 MHA 的 SSH 配置状况
masterha_check_repl //检查 MySQL 复制状况
masterha_manger //启动 manager的脚本
masterha_check_status //检测当前 MHA 运行状态
masterha_master_monitor //检测 master 是否宕机
masterha_master_switch //控制故障转移（自动或者手动）
masterha_conf_host //添加或删除配置的 server 信息
masterha_stop //关闭manager
node 安装后也会在/usr/local/bin 下面会生成几个脚本（这些工具通常由 MHAManager 的脚本触发，无需人为操作）主要如下：
save_binary_logs //保存和复制 master 的二进制日志
apply_diff_relay_logs //识别差异的中继日志事件并将其差异的事件应用于其他的 slave
filter_mysqlbinlog //去除不必要的 ROLLBACK 事件（MHA 已不再使用这个工具）
purge_relay_logs //清除中继日志（不会阻塞 SQL 线程）
在 manager 上配置到所有节点的无密码认证
在 Mysql1 上配置到其他数据库节点的无密码认证
在 Mysql2 上配置到其他数据库节点的无密码认证
在 Mysql3 上配置到其他数据库节点的无密码认证
2.5.1 在 manager 节点上复制相关脚本到/usr/local/bin 目录，拷贝后会有四个执行文件。
master_ip_failover #自动切换时 VIP 管理的脚本
master_ip_online_change #在线切换时 vip 的管理
power_manager #故障发生后关闭主机的脚本
send_report #因故障切换后发送报警的脚本
2.5.2 复制上述的自动切换时 VIP 管理的脚本到/usr/local/bin 目录，这里使用脚本管理 VIP，生产环境不太建议使用 keepalived。
修改脚本内容如下：（最好直接全部删除，复制以下内容进去）
2.5.3 创建 MHA 软件目录并拷贝配置文件。
修改配置文件
2.6.1 测试 ssh 无密码认证
如果正常最后会输出 successfully，如下所示。
2.6.2 测试 MySQL 主从连接情况
健康检查，最后出现 MySQL Replication Health is OK 字样说明
–remove_dead_master_conf #该参数代表当发生主从切换后，老的主库的 ip 将会从配置文件中移除。
–manger_log #日志存放位置。
–ignore_last_failover #在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover，之所以这样限制是为了避免 ping-pong 效应。该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA 发生切换后会在日志记目录，也就是上面设置的日志 app1.failover.complete 文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为–ignore_last_failover。
查看MHA状态，可以看到当前的 master 是 Mysql1 节点。
查看 MHA 日志，也以看到当前的 master 是 192.168.8.134
在主服务器上：使主服务器宕机
查看从服务器的状态
从服务器1（主备）：
从服务器2：
也可在manager日志上查看到过程：
重新启动原来的主数据库mysql1
同步新的主数据库（mysql2），使自己成为从服务器
查看mysql2（新的主服务器）的二进制文件和同步点
在master1 （原来的主服务器）上执行同步,查看 IO 和 SQL 线程都是 yes 代表同步是否正常
此时新的主从关系就形成了，master为mysql2，slaves为mysql1、mysql3.
MHA实现一次切换之后，会自动关闭
为了继续保证MHA功能，实现如果mysql2出现故障，能继续切换至mysql1，需要在manager服务器上修改配置文件(再把这个记录添加进去，因为它检测server1宕机的时候，server1模块会自动消失)，再开启MHA功能，即可继续监测管理。