一：软件简介
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。
在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
它由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。
MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
二：MHA服务
2.1服务角色
MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：
MHA Manager：
通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA node：
运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点。
由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。
2.2提供的工具
MHA会提供诸多工具程序， 其常见的如下所示：
Manager节点：
masterha_check_ssh ：MHA 依赖的 ssh 环境监测工具；
masterha_check_repl ：MySQL 复制环境检测工具；
masterga_manager ：MHA 服务主程序；
masterha_check_status ：MHA 运行状态探测工具；
masterha_master_monitor ：MYSQL master 节点可用性监测工具；
masterha_master_swith:master ：节点切换工具；
masterha_conf_host ：添加或删除配置的节点；
masterha_stop ：关闭 MHA 服务的工具。
Node节点：（这些工具通常由MHA Manager的脚本触发，无需人为操作）
save_binary_logs ：保存和复制 master 的二进制日志；
apply_diff_relay_logs ：识别差异的中继日志事件并应用于其他 slave；
purge_relay_logs ：清除中继日志（不会阻塞 SQL 线程）；
自定义扩展：
secondary_check_script ：通过多条网络路由检测master的可用性；
master_ip_failover_script ：更新application使用的masterip；
report_script ：发送报告;
init_conf_load_script ：加载初始配置参数；
master_ip_online_change_script ;更新master节点ip地址。
2.3工作原理
原理总结为以下几条：
（1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）；
（2） 识别含有最新更新的 slave ；
（3） 应用差异的中继日志(relay log) 到其他 slave ；
（4） 应用从 master 保存的二进制日志事件(binlog events)；
（5） 提升一个 slave 为新 master ；
（6） 使用其他的 slave 连接新的 master 进行复制。
三：实现过程
3.1准备实验MySQL的 Replication 环境
3.1.1环境配置
MHA 对 MYSQL 复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only
属性，并关闭relay_log_purge
功能等，这里对配置做事先说明。
本实验环境共有四个节点， 其角色分配如下（实验机器均为centos 7.3）：
为了方便我们后期的操作，我们在各节点的/etc/hosts文件配置内容中添加如下内容：
通过 host 解析节点来打通私钥访问，会方便很多。
1192.168.37.111 node1.keer.com node1192.168.37.122 node2.keer.com node2192.168.37.133 node3.keer.com node3192.168.37.144 node4.keer.com node4
3.1.2初始master节点配置
修改 master 的数据库配置文件来对其进行初始化配置：
1[root@master ~]# vim etc/my.cnf
2 [mysqld]
3 server-id = 1 //复制集群中的各节点的id均必须唯一
4 log-bin = master-log //开启二进制日志
5 relay-log = relay-log //开启中继日志
6 skip_name_resolve //关闭名称解析（非必须）[root@master ~]# systemctl restart mariadb
3.1.3所有slave节点依赖配置
修改两个 slave 节点的数据库配置文件：
#slave1节点
1[root@slave1 ~]# vim etc/my.cnf
2[mysqld]
3server-id = 2 //复制集群中的各节点的id均必须唯一；
4relay-log = relay-log //开启中继日志
5log-bin = master-log //开启二进制日志
6read_only = ON //启用只读属性
7relay_log_purge = 0 //是否自动清空不再需要中继日志
8skip_name_resolve //关闭名称解析（非必须）
9log_slave_updates = 1 //使得更新的数据写进二进制日志中
10[root@slave1 ~]# systemctl restart mariadb
#slave2节点
1[root@slave2 ~]# vim etc/my.cnf
2[mysqld]
3server-id = 3 //复制集群中的各节点的id均必须唯一；
4relay-log = relay-log //开启中继日志
5log-bin = master-log //开启二进制日志
6read_only = ON //启用只读属性
7relay_log_purge = 0 //是否自动清空不再需要中继日志
8skip_name_resolve //关闭名称解析（非必须）
9log_slave_updates = 1 //使得更新的数据写进二进制日志中[root@slave2 ~]# systemctl restart mariadb
3.1.4配置一主多从复制架构
master节点上：
1MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
2MariaDB [(none)]> show master status;
slave节点上：
1MariaDB [(none)]> change master to master_host='192.168.37.122',
2 -> master_user='slave',
3 -> master_password='keer', -> master_log_file='mysql-bin.000001', -> master_log_pos=415;
4MariaDB [(none)]> start slave;
5MariaDB [(none)]> show slave status\G;
3.2MHA安装配置
3.2.1在master上进行授权
在所有 Mysql 节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。 当然， 此时仅需要且只能在 master 节点运行类似如下 SQL 语句即可。
1MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';
3.2.2配置ssh免秘钥登录
MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。
简单起见，可在Manager节点生成密钥对儿，并设置其可远程连接本地主机后， 将私钥文件及authorized_keys文件复制给余下的所有节点即可。
下面操作在所有节点上进行：
1[root@manager ~]# ssh-keygen -t rsa
2[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node1
当四台机器都进行了上述操作以后，我们可以在 manager 机器上看到如下文件：
1[root@manager ~]# cd .ssh/[root@manager .ssh]# ls
2authorized_keys id_rsa id_rsa.pub known_hosts
3[root@manager .ssh]# cat authorized_keys
四台机器的公钥都已经在authorized_keys
这个文件中了，接着，我们只需要把这个文件发送至另外三台机器，这四台机器就可以实现 ssh 无密码互通了：
1[root@manager .ssh]# scp authorized_keys root@node2:~/.ssh/
2[root@manager .ssh]# scp authorized_keys root@node3:~/.ssh/
3[root@manager .ssh]# scp authorized_keys root@node4:~/.ssh/
3.2.3安装MHA
四个节点都需安装： mha4mysql-node-0.56-0.el6.norch.rpm
Manager 节点需多安装一个： mha4mysql-manager-0.56-0.el6.noarch.rpm
使用rz
命令分别上传，然后使用yum
安装即可。
1[root@manager ~]# rz
2[root@manager ~]# ls
3anaconda-ks.cfg initial-setup-ks.cfg Pictures
4Desktop mha4mysql-manager-0.56-0.el6.noarch.rpm Public
5Documents mha4mysql-node-0.56-0.el6.noarch.rpm Templates
6Downloads Music Videos
7[root@manager ~]# yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm
8[root@manager ~]# yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm
其余机器也分别进行安装，就不一一举例了。
3.2.4初始化MHA及配置
Manager 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件，而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为 /etc/masterha_default.cnf ，其为可选配置。如果仅监控一组 master/slave 集群，也可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置文件路径为自定义。具体操作见下一步骤。
3.2.5定义MHA配置管理文件
为MHA专门创建一个管理用户， 方便以后使用， 在MySQL的主节点上， 三个节点自动同步：
1mkdir etc/mha_master
2vim etc/mha_master/mha.cnf
配置文件内容如下；
1[server default] //适用于server1,2,3个server的配置user=mhaadmin //mha管理用户
2password=mhapass //mha管理密码manager_workdir=/etc/mha_master/app1 //mha_master自己的工作路径
3manager_log=/etc/mha_master/manager.log // mha_master自己的日志文件
4remote_workdir=/mydata/mha_master/app1 //每个远程主机的工作目录在何处
5ssh_user=root 基于ssh的密钥认证
6repl_user=slave 数据库用户名repl_password=magedu //数据库密码
7ping_interval=1 ping间隔时长
8[server1] 节点2
9hostname=192.168.37.133 //节点2主机地址
10ssh_port=22 节点2的ssh端口candidate_master=1 将来可不可以成为master候选节点/主节点
11[server2]
12hostname=192.168.37.133
13ssh_port=22
14candidate_master=1
15[server3]
16hostname=192.168.37.144
17ssh_port=22
18candidate_master=1
3.2.6检测4个节点
1）检测各节点间 ssh 互信通信配置是否 ok
我们在 Manager 机器上输入下述命令来检测：
1[root@manager ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf
如果最后一行显示为 [info]All SSH connection tests passed successfully 则表示成功。
2）检查管理的MySQL复制集群的连接配置参数是否OK
1[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
我们发现检测失败，这可能是因为从节点上没有账号，因为这个架构，任何一个从节点， 将有可能成为主节点， 所以也需要创建账号。
因此，我们需要在master节点上再次执行以下操作：
1MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
2MariaDB [(none)]> flush privileges;
执行完这段操作之后，我们再次运行检测命令：
1[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
2Thu Nov 23 09:07:08 2017 - [warning] Global configuration file etc/masterha_default.cnf not found. Skipping.
3Thu Nov 23 09:07:08 2017 - [info] Reading application default configuration from etc/mha_master/mha.cnf..
4Thu Nov 23 09:07:08 2017 - [info] Reading server configuration from etc/mha_master/mha.cnf..
5……
6MySQL Replication Health is OK.
3.3启动MHA
在 manager 节点上执行以下命令来启动 MHA：
1[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> etc/mha_master/manager.log &
启动成功以后，我们来查看一下 master 节点的状态：
1[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
2mha (pid:7598) is running(0:PING_OK), master:192.168.37.122
上面的信息中“mha (pid:7598) is running(0:PING_OK)”表示MHA服务运行OK，否则， 则会显示为类似“mha is stopped(1:NOT_RUNNING).”
如果，我们想要停止 MHA ，则需要使用 stop 命令：
1[root@manager ~]# masterha_stop -conf=/etc/mha_master/mha.cnf
3.4测试MHA故障转移
3.4.1 在 master 节点关闭 mariadb 服务,模拟主节点数据崩溃
1[root@master ~]# killall -9 mysqld mysqld_safe
2[root@master ~]# rm -rf var/lib/mysql/*
3.4.2 在 manger 节点查看日志
1[root@manager ~]# tail -200 etc/mha_master/manager.log
2……
3Thu Nov 23 09:17:19 2017 - [info] Master failover to 192.168.37.133(192.168.37.133:3306) completed successfully.
日志显示manager 检测到192.168.37.122节点故障， 而后自动执行故障转移， 将192.168.37.133提升为主节点。
3.5 提供新的从节点修复集群
原有 master 节点故障后，需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后，将其配置为新的 master 的从节点即可。
注意，新加入的节点如果为新增节点，其 IP 地址要配置为原来 master 节点的 IP，否则，还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ，并再次检测其状态。
我们就以刚刚关闭的那台主作为新添加的机器，来进行数据库的恢复：
原本的 slave1 已经成为了新的主机器，所以，我们对其进行完全备份，而后把备份的数据发送到我们新添加的机器上：
1[root@slave1 ~]# mkdir backup
2[root@slave1 ~]# mysqldump --all-database > backup/mysql-backup-`date +%F-%T`-all.sql
3[root@slave1 ~]# scp backup/mysql-backup-2017-11-23-09\:57\:09-all.sql root@node2:~
然后在 node2 节点上进行数据恢复：
1[root@master ~]# mysql < mysql-backup-2017-11-23-09\:57\:09-all.sql
接下来就是配置主从。照例查看一下现在的主的二进制日志和位置，然后就进行如下设置：
1MariaDB [(none)]> change master to master_host='192.168.37.133', master_user='slave', master_password='keer', master_log_file='mysql-bin.000006', master_log_pos=925;
2MariaDB [(none)]> start slave;
3MariaDB [(none)]> show slave status\G;
4 Slave_IO_State: Waiting for master to send event
5 Master_Host: 192.168.37.133
6 Master_User: slave
7 Master_Port: 3306
8 Connect_Retry: 60
9 Master_Log_File: mysql-bin.000006
10 Read_Master_Log_Pos: 925
11 Relay_Log_File: mysql-relay-bin.000002
12 Relay_Log_Pos: 529
13 Relay_Master_Log_File: mysql-bin.000006
14 Slave_IO_Running: Yes
15 Slave_SQL_Running: Yes
16 ……
3.6 新节点提供后再次执行检查操作
再次检测状态：
1[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
2[root@manager ~]# masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log 2>&1 &[1] 10012
启动成功以后，我们来查看一下 master 节点的状态：
1[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
2mha (pid:9561) is running(0:PING_OK), master:192.168.37.133
3.7新节点上线， 故障转换恢复注意事项
1）在生产环境中， 当你的主节点挂了后， 一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点， 并指明从哪一个日志文件的位置开始复制；
2）每一次自动完成转换后， 每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点， 除非你改配置文件；
3）手动修复主节点提升为从节点后， 再次运行检测命令；
1[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
2mha (pid:9561) is running(0:PING_OK), master:192.168.37.133
4）再次运行起来就恢复成功了；
1[root@manager ~]# masterha_manager --conf=/etc/mha_master/mha.cnf
以上的实验已经圆满完成。
