MHA实现Mysql高可用集群
MHA简介：
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA组成：
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
Manager工具包主要包括以下几个工具：
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_manger 启动MHA
masterha_check_status 检测当前MHA运行状态
masterha_master_monitor 检测master是否宕机
masterha_master_switch 控制故障转移（自动或者手动）
masterha_conf_host 添加或删除配置的server信息
Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
MHA工作原理：
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。
官方介绍：https://code.google.com/p/mysql-master-ha/
下图展示了如何通过MHA Manager管理多组主从复制。结构如下：
一、实验环境准备
系统版本
1 [root@vin ~]# cat /etc/redhat-release 2 CentOS Linux release 7.3.1611 (Core)
内核参数
1 [root@vin ~]# uname -r 2 3.10.0-514.el7.x86_64
主机配置参数：准备四台干净的虚拟机node{1,2,3,4}
角色 ip地址 主机名 server_id 类型 MHA-Manager 172.18.253.73 node1 - 监控复制组 Master 172.18.250.27 node2 1 写入 Candicate master 172.18.253.160 node3 2 读 Slave 172.18.254.15 node4 3 读
实现互相能够解析主机名：
1 [root@vin ~]# cat /etc/hosts 2 172.18.253.73 node1 3 172.18.250.27 node2 4 172.18.253.160 node3 5 172.18.254.15 node4
实现四台主机间的两两互相无密钥通信：
1 [root@vin ~]# ssh-keygen -t rsa -P '' 2 [root@vin ~]# ssh-copy-id -i ./id_rsa.pub node1: 3 [root@vin ~]# for i in {2..4};do scp id_rsa{,.pub} authorized_keys root@node$i:/root/.ssh/;done
二、实现主从复制集群
Master配置：
修改配置文件
1 [root@vin ~]# cat /etc/my.cnf.d/server.cnf 2 [server] 3 server_id = 1 4 log_bin = master-log 5 relay_log = relay-log 6 7 innodb_file_per_table = ON 8 skip_name_resolve = ON 9 max_connections = 5000
创建具有复制功能的用户与用于Manager节点管理的用户；
1 [root@vin ~]# mysql 2 MariaDB [(none)]> show master status\G; 3 *************************** 1. row *************************** 4 File: master-log.000003 5 Position: 245 6 Binlog_Do_DB: 7 Binlog_Ignore_DB: 8 MariaDB [(none)]> grant replication slave,replication client on *.* to 'vinsent'@'172.18.%.%' identified by 'vinsent'; 9 MariaDB [(none)]> grant ALL on *.* to 'MhaAdmin'@'172.18.%.%' identified by 'MhaPass'; 10 MariaDB [(none)]> flush privileges;
说明：我们应该先查看主节点正在使用的日志文件及对应的POSITION，再创建用户，以便于从节点能够同步拥有这些用户；创建Manager节点用于管理的用户时需要注意的是，用户名中的主机范围必须能够囊括其他节点的地址。
Slave{1,2}配置：
两个从节点的配置相同；修改配置文件，以支持主从复制功能
1 [root@vin ~]# cat /etc/my.cnf.d/server.cnf 2 [server] 3 server_id = 2 4 log_bin = master-log 5 relay_log = relay-log 6 7 relay_log_purge = OFF 8 read_only = ON 9 10 innodb_file_per_table = ON 11 skip_name_resolve = ON 12 max_connections = 5000
连接至主节点，实现同步；
1 [root@vin ~]# mysql 2 MariaDB [(none)]> change master to master_host='172.18.250.27',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245; 3 MariaDB [(none)]> start slave; 4 MariaDB [(none)]> show slave status\G; 5 *************************** 1. row *************************** 6 Slave_IO_State: Waiting for master to send event 7 Master_Host: 172.18.250.27 8 Master_User: vinsent 9 Master_Port: 3306 10 Connect_Retry: 60 11 Master_Log_File: master-log.000003 12 Read_Master_Log_Pos: 637 13 Relay_Log_File: relay-log.000002 14 Relay_Log_Pos: 922 15 Relay_Master_Log_File: master-log.000003 16 Slave_IO_Running: Yes 17 Slave_SQL_Running: Yes 18 Replicate_Do_DB: 19 Replicate_Ignore_DB: 20 Replicate_Do_Table: 21 Replicate_Ignore_Table: 22 Replicate_Wild_Do_Table: 23 Replicate_Wild_Ignore_Table: 24 Last_Errno: 0 25 Last_Error: 26 Skip_Counter: 0 27 Exec_Master_Log_Pos: 637 28 Relay_Log_Space: 1210 29 Until_Condition: None 30 Until_Log_File: 31 Until_Log_Pos: 0 32 Master_SSL_Allowed: No 33 Master_SSL_CA_File: 34 Master_SSL_CA_Path: 35 Master_SSL_Cert: 36 Master_SSL_Cipher: 37 Master_SSL_Key: 38 Seconds_Behind_Master: 0 39 Master_SSL_Verify_Server_Cert: No 40 Last_IO_Errno: 0 41 Last_IO_Error: 42 Last_SQL_Errno: 0 43 Last_SQL_Error: 44 Replicate_Ignore_Server_Ids: 45 Master_Server_Id: 1
说明：查看从节点状态，确保"Slave_IO_Running","Slave_SQL_Running"的值为"YES"，即从节点正常工作，并且"Last_IO_Errno","Last_SQL_Errno"中没有错误信息提示，出现错误，一般就是连接性错误，这说明要么用户创建的有问题，要么主从节点的数据不同步，请确保两者数据一致。
测试一下从节点是否将主节点的数据同步至本地：
1 MariaDB [(none)]> select user from mysql.user; 2 +----------+ 3 | user | 4 +----------+ 5 | root | 6 | MhaAdmin | 7 | vinsent | 8 | root | 9 | | 10 | root | 11 | | 12 | root | 13 +----------+
三、安装MHA包
除了源码包，MHA官方也提供了rpm格式的程序包，其下载地址为http://code.google.com/p/mysql-master/wiki/Downloads?tm=2。CentOS 7 系统可直接使用适用于el6的程序包，另外，MHA Manager和MHA NODe程序包的版本并不强制要求一致。
Manager节点：
1 [root@vin ~]# ls 2 mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm 3 [root@vin ~]# yum install /root/*.rpm # 使用yum安装可执行解决依赖性，前提是你的yum源配置正确
Master && SLave{1,2}节点：
1 [root@vin ~]# ls 2 mha4mysql-node-0.56-0.el6.noarch.rpm 3 [root@vin ~]# yum install /root/*.rpm
四、初始化MHA
MHA的配置文件符合ini风格，可定义一个默认的配置文件用于存放一些公共的基础配置，该文件放置于/etc/且命名为masterha_default.cnf,也可以所有的Master/Slave集群共享一个全局配置。如果仅仅监控一致集群，可直接通过application的配置来提供各服务器的默认配置信息，而每个application的配置文件路径为自定义，例如：
Manager节点：
1 [root@vin ~]# mkdir /etc/masterha/ 2 [root@vin ~]# vim /etc/masterha/app1.cnf 3 [server default] 4 user=MhaAdmin 5 password=MhaPass 6 manager_workdir=/data/masterha/app1 7 manager_log=/data/masterha/manager.log 8 remote_workdir=/data/masterha/app1 # 远程主机的工作目录 9 ssh_user=root # ssh连接的用户名；由于实现了ssh无密钥登录，这里就不用再指定密码了 10 #ssh_password= 11 repl_user=vinsent # 从节点连接至主节点同步的用户名及密码；因为如果主节点故障，将有新的主节点产生 12 repl_password=vinsent 13 ping_interval=1 # 监控每台服务器是否健康时延，单位s 14 15 [server1] 16 hostname=172.18.250.27 17 candidate_master=1 # 是否会成为未来的主节点，这里他就是默认得主节点 18 19 [server2] 20 hostname=172.18.253.160 21 candidate_master=1 22 23 [server3] 24 hostname=172.18.254.15 25 candidate_master=1
检测各节点之间ssh可用性
1 [root@vin ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf 2 ... 3 - [info] All SSH connection tests passed successfully. # 出现该提示，则说明ssh可用
检测管理的mysql主从复制集群的连接配置参数是否满足
1 [root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf 2 ... 3 Mon Nov 13 22:11:30 2017 - [info] Slaves settings check done. 4 Mon Nov 13 22:11:30 2017 - [info] 5 172.18.250.27(172.18.250.27:3306) (current master) 6 +--172.18.253.160(172.18.253.160:3306) 7 +--172.18.254.15(172.18.254.15:3306) 8 ... 9 MySQL Replication Health is OK.
启动MHA
1 [root@vin ~]# masterha_manager --conf=/etc/masterha/app1.cnf 2 Mon Nov 13 22:16:17 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. # 没有默认配置文件出现的警告信息，可忽略 3 Mon Nov 13 22:16:17 2017 - [info] Reading application default configuration from /etc/masterha/app1.cnf.. 4 Mon Nov 13 22:16:17 2017 - [info] Reading server configuration from /etc/masterha/app1.cnf..
说明：MHA默认是工作在前台的，要想将它防止至后台运行，可使用下面的命令：
[root@vin ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/managerha/manager.log 2&>1 &
成功启动之后，查看一下Master节点的状态
1 [root@vin ~]# masterha_check_status --conf=/etc/masterha/app1.cnf 2 app1 (pid:4090) is running(0:PING_OK), master:172.18.250.27
说明：如果未成功启动，这里的命令将不能够正确执行；提示："app1 is stopped(2:NOT_RUNNING)."
五、配置keepalived
设置为用户提供服务的地址为"172.18.14.55/16",通过keepalived实现VIP在Mysql复制集群中浮动。
安装keepalived:
在Mysql复制集群的所有主机上都安装配置keepalived
1 [root@vin ~]# yum install keepalived -y
修改keepalived配置文件实现keepalived集群：
Master：
1 [root@vin ~]# vim /etc/keepalived/keepalived.conf 2 ! Configuration File for keepalived 3 4 global_defs { 5 notification_email { 6 root@localhost 7 } 8 notification_email_from kadmin@localhost 9 smtp_server 127.0.0.1 10 smtp_connect_timeout 30 11 router_id LVS_DEVEL 12 route_mcast_group4 224.14.0.14 13 } 14 15 vrrp_script chk_mysql { 16 script "killall -0 mysql" # 监控mysql是否工作正常的脚本 17 insterval 1 # 没秒探测一次 18 weight -10 # 如果出现异常，即mysql服务不可用，则将优先级下调10 19 } 20 21 vrrp_instance VI_1 { 22 state BACKUP 23 interface ens33 24 virtual_router_id 66 25 priority 98 # 优先级 26 advert_int 1 27 authentication { 28 auth_type PASS 29 auth_pass 1111 30 } 31 virtual_ipaddress { 32 172.18.14.55/16 # vip地址 33 } 34 track_script { 35 chk_mysql # 调用监控脚本 36 } 37 38 }
复制该配置文件至其他Slave节点：
1 [root@vin ~]# for i in {3,4};do scp /etc/keepalived/keepalived.conf root@node$i:/etc/keepalived/ ;done
复制过去并不能直接使用，由于keepalived通过优先级机制来决定VIP工作在哪台主机，所以将两个从节点的优先级调节至比主节点上keepalived的优先级低，且互相不同。
有心的人可能发现问题了，怎么没有修改VRRP实例的状态"state BACKUP";上面服务器的keepalived都设置为了BACKUP模式，在keepalived中2种模式，分别是master->backup模式和backup->backup模式。这 两种模式有很大区别。在master->backup模式下，一旦主节点宕机，虚拟ip会自动漂移到从节点，当主节点修复后，keepalived启动后，还会把虚拟ip抢占过来，即使设置了非抢占模式（nopreempt）抢占ip的动 作也会发生。在backup->backup模式下，当主节点故障后虚拟ip会自动漂移到从节点上，当原主节点恢复后，并不会抢占新主的虚拟ip，即使是优先级高于从库的优先级别，也不会发生抢占。为了减少ip漂移次 数，通常是把修复好的主库当做新的备库。
六、故障出现
模拟故障发生，我们手动"down"掉了主节点
Master：
1 [root@vin ~]# systemctl stop mariadb
在MHA节点上查看MHA的状态
1 [root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf 2 .... 3 Mon Nov 13 22:36:37 2017 - [info] MHA::MasterMonitor version 0.56. 4 Mon Nov 13 22:36:37 2017 - [info] GTID failover mode = 0 5 Mon Nov 13 22:36:37 2017 - [info] Dead Servers: # 指明故障的节点 6 Mon Nov 13 22:36:37 2017 - [info] 172.18.250.27(172.18.250.27:3306) 7 Mon Nov 13 22:36:37 2017 - [info] Alive Servers: 8 Mon Nov 13 22:36:37 2017 - [info] 172.18.253.160(172.18.253.160:3306) 9 Mon Nov 13 22:36:37 2017 - [info] 172.18.254.15(172.18.254.15:3306) 10 Mon Nov 13 22:36:37 2017 - [info] Alive Slaves: 11 Mon Nov 13 22:36:37 2017 - [info] 172.18.254.15(172.18.254.15:3306) # 从节点由两个转为了一个，另为一个升级为主节点 12 ....
在从节点进行测试看主节点是否正确切换
Slave1：
1 MariaDB [(none)]> show slave status; # 查看从节点状态为空，说明已非从节点 2 Empty set (0.00 sec) 3 4 MariaDB [(none)]> show master status; # 再查看master状态，已正确切换 5 +-------------------+----------+--------------+------------------+ 6 | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | 7 +-------------------+----------+--------------+------------------+ 8 | master-log.000003 | 245 | | | 9 +-------------------+----------+--------------+------------------+
Slave2：
MariaDB [(none)]> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.18.253.160 # 从节点"Slave2"已经将主节点指向了新的主节点 Master_User: vinsent Master_Port: 3306 Connect_Retry: 60 Master_Log_File: master-log.000003 ...
查看keepalived地址绑定情况：
Master：
1 [root@vin ~]# ip a | grep ens33 2 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 3 inet 172.18.250.27/16 brd 172.18.255.255 scope global dynamic ens33
Save1：
1 [root@vin ~]# ip a | grep ens33 2 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 3 inet 172.18.250.160/16 brd 172.18.255.255 scope global dynamic ens33 4 inet 172.18.14.55/16 scope global secondary ens33 # 地址正确漂移至从节点Slave1
Slave2：
1 [root@vin ~]# ip a | grep ens33 2 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 3 inet 172.18.254.15/16 brd 172.18.255.255 scope global dynamic ens33
七、故障恢复
为了满足集群要求，应当立即将故障的主节点修复上线。由于Mysql复制集群的主节点已然切换，那么故障的原主节点上线之后只能为从节点，所以应当修改其配置文件满足从节点的要求。
Master：
1 [root@vin ~]# vim /etc/my.cnf.d/server.cnf # 添加如下两项 2 [server] 3 relay_log_purge = OFF 4 read_only = ON
启动服务，并连接Mysql；并连接至新的主节点做主从同步；这里值得注意的是：如果你的主节点是在运行过程中故障宕机来了，那么你要做的就不仅仅是修改配置，启动服务了。修改配置文件之后，应当对新主做一个完全备份，将新主节点的数据恢复至本机，然后在连接至新的主节点做复制同步（本实验没有太多的数据，故直接上线）。
1 [root@vin ~]# systemctl start mariadb 2 [root@vin ~]# mysql 3 MariaDB [(none)]> change master to master_host='172.18.253.160',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245; 4 MariaDB [(none)]> start slave; 5 MariaDB [(none)]> show slave status\G 6 *************************** 1. row *************************** 7 Slave_IO_State: Waiting for master to send event 8 Master_Host: 172.18.253.160 9 Master_User: vinsent 10 Master_Port: 3306 11 ...
切换至MHA上并查看集群状态
1 [root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf 2 ... 3 Mon Nov 13 22:54:53 2017 - [info] GTID failover mode = 0 4 Mon Nov 13 22:54:53 2017 - [info] Dead Servers: 5 Mon Nov 13 22:54:53 2017 - [info] Alive Servers: 6 Mon Nov 13 22:54:53 2017 - [info] 172.18.250.27(172.18.250.27:3306) # 由于没有在配置文件中指明谁是主，故这里只能看到所有工作的主机 7 Mon Nov 13 22:54:53 2017 - [info] 172.18.253.160(172.18.253.160:3306) 8 Mon Nov 13 22:54:53 2017 - [info] 172.18.254.15(172.18.254.15:3306) 9 Mon Nov 13 22:54:53 2017 - [info] Alive Slaves: 10 Mon Nov 13 22:54:53 2017 - [info] 172.18.250.27(172.18.250.27:3306) 11 ... 12 MySQL Replication Health is OK.
启动MHA Manger监控，查看集群里面现在谁是master
1 [root@vin ~]# masterha_check_status --conf=/etc/masterha/app1.cnf 2 app1 is stopped(2:NOT_RUNNING).
？？？怎么回事，明明已经正确启动，为何此处显示为“stopped”；赶紧去官网一查发现："Currently MHA Manager process does not run as a daemon. If failover completed successfully or the master process was killed by accident, the manager stops working. To run as a daemon, daemontool. or any external daemon program can be used. Here is an example to run from daemontools.",原来如此
八、总结
查日志观察切换过程分析MHA切换过程：
1 [root@vin masterha]# cat manager.log 2 Mon Nov 13 22:36:03 2017 - [info] MHA::MasterMonitor version 0.56. 3 Mon Nov 13 22:36:04 2017 - [info] GTID failover mode = 0 4 Mon Nov 13 22:36:04 2017 - [info] Dead Servers: 5 Mon Nov 13 22:36:04 2017 - [info] 172.18.250.27(172.18.250.27:3306) 6 Mon Nov 13 22:36:04 2017 - [info] Alive Servers: 7 Mon Nov 13 22:36:04 2017 - [info] 172.18.253.160(172.18.253.160:3306) 8 Mon Nov 13 22:36:04 2017 - [info] 172.18.254.15(172.18.254.15:3306) 9 Mon Nov 13 22:36:04 2017 - [info] Alive Slaves: 10 Mon Nov 13 22:36:04 2017 - [info] 172.18.254.15(172.18.254.15:3306) Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled 11 Mon Nov 13 22:36:04 2017 - [info] Replicating from 172.18.253.160(172.18.253.160:3306) 12 Mon Nov 13 22:36:04 2017 - [info] Primary candidate for the new Master (candidate_master is set) 13 Mon Nov 13 22:36:04 2017 - [info] Current Alive Master: 172.18.253.160(172.18.253.160:3306) 14 Mon Nov 13 22:36:04 2017 - [info] Checking slave configurations.. 15 Mon Nov 13 22:36:04 2017 - [warning] relay_log_purge=0 is not set on slave 172.18.254.15(172.18.254.15:3306). 16 Mon Nov 13 22:36:04 2017 - [info] Checking replication filtering settings.. 17 Mon Nov 13 22:36:04 2017 - [info] binlog_do_db= , binlog_ignore_db= 18 Mon Nov 13 22:36:04 2017 - [info] Replication filtering check ok. 19 Mon Nov 13 22:36:04 2017 - [info] GTID (with auto-pos) is not supported 20 Mon Nov 13 22:36:04 2017 - [info] Starting SSH connection tests.. 21 Mon Nov 13 22:36:05 2017 - [info] All SSH connection tests passed successfully. 22 Mon Nov 13 22:36:05 2017 - [info] Checking MHA Node version.. 23 Mon Nov 13 22:36:06 2017 - [info] Version check ok. 24 Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln492] Server 172.18.250.27(172.18.250.27:3306) is dead, but must be alive! Check server settings. 25 Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 399. 26 Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. 27 Mon Nov 13 22:36:06 2017 - [info] Got exit code 1 (Not master dead). 28 Mon Nov 13 22:36:13 2017 - [info] MHA::MasterMonitor version 0.56. 29 Mon Nov 13 22:36:13 2017 - [info] GTID failover mode = 0 30 Mon Nov 13 22:36:13 2017 - [info] Dead Servers: 31 Mon Nov 13 22:36:13 2017 - [info] 172.18.250.27(172.18.250.27:3306) 32 Mon Nov 13 22:36:13 2017 - [info] Alive Servers: 33 Mon Nov 13 22:36:13 2017 - [info] 172.18.253.160(172.18.253.160:3306) 34 Mon Nov 13 22:36:13 2017 - [info] 172.18.254.15(172.18.254.15:3306) 35 Mon Nov 13 22:36:13 2017 - [info] Alive Slaves: 36 Mon Nov 13 22:36:13 2017 - [info] 172.18.254.15(172.18.254.15:3306) Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled 37 Mon Nov 13 22:36:13 2017 - [info] Replicating from 172.18.253.160(172.18.253.160:3306) 38 Mon Nov 13 22:36:13 2017 - [info] Primary candidate for the new Master (candidate_master is set) 39 Mon Nov 13 22:36:13 2017 - [info] Current Alive Master: 172.18.253.160(172.18.253.160:3306) 40 Mon Nov 13 22:36:13 2017 - [info] Checking slave configurations.. 41 Mon Nov 13 22:36:13 2017 - [warning] relay_log_purge=0 is not set on slave 172.18.254.15(172.18.254.15:3306). 42 Mon Nov 13 22:36:13 2017 - [info] Checking replication filtering settings.. 43 Mon Nov 13 22:36:13 2017 - [info] binlog_do_db= , binlog_ignore_db= 44 Mon Nov 13 22:36:13 2017 - [info] Replication filtering check ok. 45 Mon Nov 13 22:36:13 2017 - [info] GTID (with auto-pos) is not supported 46 Mon Nov 13 22:36:13 2017 - [info] Starting SSH connection tests.. 47 Mon Nov 13 22:36:15 2017 - [info] All SSH connection tests passed successfully. 48 Mon Nov 13 22:36:15 2017 - [info] Checking MHA Node version.. 49 Mon Nov 13 22:36:15 2017 - [info] Version check ok. 50 Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln492] Server 172.18.250.27(172.18.250.27:3306) is dead, but must be alive! Check server settings. 51 Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 399. 52 Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. 53 Mon Nov 13 22:36:15 2017 - [info] Got exit code 1 (Not master dead).
从上面的输出可以看出整个MHA的切换过程，共包括以下的步骤：
配置文件检查阶段，这个阶段会检查整个集群配置文件配置
宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作（这个我这里还没有实现，需要研究）
复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下
识别含有最新更新的slave
应用从master保存的二进制日志事件（binlog events）
提升一个slave为新的master进行复制
使其他的slave连接新的master进行复制
目前高可用方案可以一定程度上实现数据库的高可用，比如前面文章介绍的MMM，heartbeat+drbd，Cluster等。还有percona的Galera Cluster等。这些高可用软件各有优劣。在进行高可用方案选择时，主要是看业务还有对数据一致性方面的要求。最后出于对数据库的高可用和数据一致性的要求，推荐使用MHA架构。
