LAMP架构之9——MySQL高可用切换(MHA)

Posted 2023-03-23 Zhaohui_Zhang

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了LAMP架构之9——MySQL高可用切换(MHA)相关的知识，希望对你有一定的参考价值。

一、MySQL高可用切换(MHA)

1、实验环境：将上一实验中的“组复制”结构改成“一主两从”的结构。

2、在server4中安装MHA软件(server4作为MHA管理端)

3、master端和slave端安装的软件包主要是一些二进制程序/工具：

4、MHA管理端的配置文件(在server4中设置)

5、创建本机mha的配置文件及目录，并生成配置文件

6、修改配置文件

7、脚本检查——两个脚本检查mha是否配置完成(检查通过证明环境配置成功)

8、MHA管理集群节点的master切换——手动切换

9、MHA管理集群节点的master切换——自动切换

10、MHA管理集群节点的master切换——脚本执行(VIP漂移)

本章总结：

一、mysql高可用切换(MHA)

1、实验环境：将上一实验中的“组复制”结构改成“一主两从”的结构。

设置master：

停止mysql——>清除环境——>更改配置文件——>初始化——>启动mysql——>修改密码——>创建用户并设置密码(如下)——>查看状态

grant replication slave on *.* to repl@'%' identified by 'westos';   #添加授权并设置密码

设置slave：

配置文件更改如下(和master的配置文件大同小异)

其余步骤如上，更改完密码后的步骤有所不同。需要设置要跟随的master服务器并启动slave。

mysql> change master to master_host='172.25.254.1', master_user='repl', master_password='westos', master_auto_position=1;            #设置master信息
mysql> start slave;                                    #启动slave
mysql> show slave status\\G;                            #查看slave状态

2、在server4中安装MHA软件(server4作为MHA管理端)

先下载相关的安装包，解压后安装MHA管理端软件(其他软件为依赖性)，同时一起安装了。

注意：MHA在工作时要求管理端可以免密连接所有受控端，所以还需要做一个免密认证。

受控端需要安装“node”节点的软件，通过scp方式发送给所有受控端并安装。

3、master端和slave端安装的软件包主要是一些二进制程序/工具：

4、MHA管理端的配置文件(在server4中设置)

mha安装好以后，默认是没有配置文件的。可以从之前解压的那个软件包里找到模板。

如下图所示：</root/mha/mha4mysql-manager-0.58/samples/conf>下的两个配置文件的模板，一个是全局配置模板，即对集群中所有的主从结构都生效；另一个是局部配置模板，只对特定的主从结构生效。

5、创建本机mha的配置文件及目录，并生成配置文件

6、修改配置文件</etc/mha/app1.conf>

[server default]
user=root                        #用户的远程登录用户
password=westos
ssh_user=root                    #免密认证用户身份
repl_user=repl                   #登录的数据库及密码
repl_password=westos
master_binlog_dir=/data/mysql    #源码编译的数据库位置
remote_workdir=/tmp              #远程工作路径
secondary_check_script= masterha_secondary_check -s 172.25.254.2 -s 172.25.254.3
           #指定的两个地址一般应为集群外的其他集群地址。此语句用于和受控集群失俩联时寻找的主机
ping_interval=3                  #每隔3秒钟对集群节点作一次监测，看网络状如是否健康。

# master_ip_failover_script= /script/masterha/master_ip_failover
# shutdown_script= /script/masterha/power_manager
# report_script= /script/masterha/send_report
# master_ip_online_change_script= /script/masterha/master_ip_online_change

manager_workdir=/etc/mha          #要管理的数据目录
manager_log=/etc/mha/manager.log         #日志文件

[server1]
hostname=172.25.254.1            
candidate_master=1                #设置此节点为master

[server2]
hostname=172.25.254.2
candidate_master=1                #设置此节点为备用master(只有当主节点挂了才会生效)
check_repl_delay=0                  #设置为0表示不管此节点落后主节点多少，都会等这个节点

[server3]
hostname=172.25.254.3
no_master=1                        #设置此节点只能作为slave

7、脚本检查——两个脚本检查mha是否配置完成(检查通过证明环境配置成功)

masterha_check_ssh --conf=/etc/mha/app1.conf         #检查免密是否通过

检查免密认证时是否通过，出现如下错误。由此可知，不仅MHA管理器要对节点免密访问，集群节点之间也要做到免密认证！！！

直接复制公钥和密钥。

由于之前server4和server1/2/3之间都经过免密认证，所以server4的“钥匙”和server1/2/3的“锁”是一对，因此只要将server4的“钥匙”再发放给server1/2/3就可以实现所有主机之间的免密认证。

再次运行脚本检查，检查没有错误了。

masterha_check_repl --conf=/etc/mha/app1.conf         #监测数据库主从之间的配置是否到位

错误表示，server4通过root身份远程连接节点的数据库时认证失败。这是因为mysql数据库中对远程登录的root用户身份没有授权。因此下一步需要授权访问。

在master中添加授权(在任何节点都可以此操作)。

grant all on *.* to root@'%' identified by 'westos';        #添加授权
flush privileges;                                           #刷新

在MHA中重新检查，检查通过！！！

8、MHA管理集群节点的master切换——手动切换

情况一：当前的master正常运行时。

masterha_master_switch             
--conf=/etc/mha/app1.conf                     #读取的配置文件
--master_state=alive                          #如果现存的master活着的情况下
--new_master_host=172.25.254.2                #新master的IP
--new_master_port=3306                        #新master的端口
--orig_master_is_new_slave                    #原master变成slave
--running_updates_limit=10000                 #切换等待时间10000毫秒

执行后，一路“yes”到底。

执行过程中显示，原来的主从结构的master已经由server1转换为server2了

检查节点状态

情况二：当前的master出现故障时。

先停止上一步中server2设置的master。

masterha_master_switch 
--master_state=dead                             #当现存的msater挂掉时
--conf=/etc/mha/app1.conf                       #mha的配置文件
--dead_master_host=172.25.254.2                 #挂掉的master节点IP
--dead_master_port=3306                         #挂掉节点的端口
--new_master_host=172.25.254.1                  #新的master节点IP
--new_master_port=3306                          #新的master节点的端口
--ignore_last_failover                          #忽略最近的一次错误连接

执行过程中显示，原来的主从结构的master已经故障了，且新的master转换为了server1

检查节点状态

重新启用节点server2，启用后会自动连接当前的master

9、MHA管理集群节点的master切换——自动切换

第一步：用管理命令将读取配置文件并打入后台运行

masterha_manager --conf=/etc/mha/app1.conf  &

查看进程，masterha_manager进程已在后台运行，意味着正在监控集群中的节点。

监控的日志会存放在</etc/mha/manager.log>中。

第二步：关闭master节点并测试MHA性能

关闭master节点的mysql服务，MHA端会自动有反应

注意：上一步中执行完<masterha_manager>命令后，会在配置文件目录下生成一个“锁定文件”<app1.failover.complete>，这个“锁定文件”会影响自动切换，因此每次用完以后都要删除。

下图表示：监控到master节点挂掉以后，已经重新切换到其他节点作为master了。同时此进程生效一次后就消失了，避免了频繁切换master节点的问题。

查看日志</etc/mha/manager.conf>，日志中显示master节点已经从server1切换到server2上。

检查节点状态，在server2中已经查不到slave状态了，但是有master状态；server3中查看slave状态，其指向的master是server2.

10、MHA管理集群节点的master切换——脚本执行(VIP漂移)

因为master的IP如果发生改变，会对用户造成影响。因此需要设定VIP(虚拟IP)，无论master如何改变，VIP始终指向最新的master。

在刚开始的哪个压缩包中有脚本的示例。

其中<master_ip_failover>是自动切换脚本，<master_ip_online_change>是手动切换脚本；<power_manager>是服务器电源管理脚本，<send_report>是节点故障时发送报警的脚本。

第一步：更改mha的配置文件

之前的配置文件中注释掉了这些脚本的路径，需要执行脚本时就把它们重新打开。脚本放在那里都可以，这里的脚本路径要写对。

第二步：下载脚本并添加可执行权限

自动切换的脚本：

脚本内容表示的是VIP地址设置为<172.25.254.100>，通过的网卡为<eth0>。

手动切换的脚本：

脚本内容表示的是VIP地址设置为<172.25.254.100>，通过的网卡为<eth0>。

手动切换脚本：

第一步：向server2中添加虚拟IP

由之前的实验可得，master节点已经切换到server2了。所以可以向server2中添加虚拟IP。

第二步：在客户端中测试

客户端通过虚拟IP可以访问mysql数据库

第三步：手动切换master到server1

切换完成后，server2和server3的都成为了slave节点，都跟随server1.

第四步：客户端查看

客户端再次查看时，会短期报错，然后重新连接。重连结果也会正常访问mysql。

这是因为VIP已经从server2切换到了server1中

自动切换脚本：

第一步：先在server2或1中添加VIP

第二步：执行自动切换的命令并打入后台，命令如下：

masterha_manager --conf=/etc/mha/app1.conf &

第三步：关闭目前的master

在上一步实验中，master已经切换到了server1中。因此本次要关闭server的master(产生master节点故障)。

第四步：查看MHA

由于MHA中存在自动执行的命令，并在后台运行，因此server1节点挂掉后，会自动切换到server2节点。查看日志可已看出，master已经成功切换到server2节点。

第五步：查看server2状态

上一步master自动切换到server2以后，查看server2状态。不用再作其他配置，已经可以作为正常的master节点了。server3也正常指向server2节点作为master了。

第六步：查看VIP

此是VIP已经自动从server1漂移到了server2中。

本章总结：

1、查询mysql中的模块/插件：

show plugins;

2、查询数据库中的线程

show processlist;          #显示数据库线程

以下展现出来的两个线程，第一个是SQL线程，第二个是IO线程

3、集群分类

MySQL异步复制：

MySQL半同步复制：

MySQL组复制协议：

4、mysql组复制时的参数

5、mysql的配置文件参数

永久设置：</etc.my.cnf>

group_replication_bootstrap_group=OFF;

临时设置：<mysql>内部

SET GLOBAL group_replication_bootstrap_group=OFF;

MySQL高可用架构之MHA

MySQL高可用架构之MHA简单搭建

简介：

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为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自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。另外对于想快速搭建的可以参考：MHA快速搭建

我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。

官方介绍：https://code.google.com/p/mysql-master-ha/

图01展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下：

（图01 ）

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。

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的同时建议配置成MySQL 5.5的半同步复制。关于半同步复制原理各位自己进行查阅。（不是必须）

1.部署MHA

接下来部署MHA，具体的搭建环境如下（所有操作系统均为centos 7 1804，不是必须，slave1和slave2是maset的从，复制环境搭建后面会简单演示，但是相关的安全复制不会详细说明，需要的童鞋请参考前面的文章，MySQL Replication需要注意的问题）：

角色                          ip地址                    server_id            类型
Monitor host            192.168.134.191              -                监控复制组
Master                  192.168.134.193              1                写入
slave1                  192.168.134.2                2                读
Slave2                  192.168.134.194              3                读

其中master对外提供写服务，备选master提供读服务，也提供相关的读服务，一旦master宕机，将会把备选master（slave1/2）提升为新的master，slave1/2指向新的master（slave2/1）

因为事先下载好的

yum install mha4mysql-*

查看MHA提供了多少东西

[[email protected] ~]# rpm -ql mha4mysql-manager
./usr/bin/masterha_check_repl
/usr/bin/masterha_check_ssh
/usr/bin/masterha_check_status
/usr/bin/masterha_conf_host
/usr/bin/masterha_manager
/usr/bin/masterha_master_monitor
/usr/bin/masterha_master_switch
/usr/bin/masterha_secondary_check
/usr/bin/masterha_stop
/usr/share/man/man1/masterha_check_repl.1.gz
/usr/share/man/man1/masterha_check_ssh.1.gz
/usr/share/man/man1/masterha_check_status.1.gz
/usr/share/man/man1/masterha_conf_host.1.gz
/usr/share/man/man1/masterha_manager.1.gz
/usr/share/man/man1/masterha_master_monitor.1.gz
/usr/share/man/man1/masterha_master_switch.1.gz
/usr/share/man/man1/masterha_secondary_check.1.gz
/usr/share/man/man1/masterha_stop.1.gz
/usr/share/perl5/vendor_perl/MHA/Config.pm
/usr/share/perl5/vendor_perl/MHA/DBHelper.pm
/usr/share/perl5/vendor_perl/MHA/FileStatus.pm
/usr/share/perl5/vendor_perl/MHA/HealthCheck.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdmin.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdminWrapper.pm
/usr/share/perl5/vendor_perl/MHA/ManagerConst.pm
/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm
/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm
/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm
/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm
/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm
/usr/share/perl5/vendor_perl/MHA/Server.pm
/usr/share/perl5/vendor_perl/MHA/ServerManager.pm

2.配置SSH登录无密码验证（使用key登录，工作中常用）我的测试环境已经是使用key登录，服务器之间无需密码验证的。关于配置使用key登录，我想我不再重复。但是有一点需要注意：不能禁止 password 登陆，否则会出现错误

3.搭建主从复制环境

注意：binlog-do-db 和 replicate-ignore-db 设置必须相同。 MHA 在启动时候会检测过滤规则，如果过滤规则不同，MHA 不启动监控和故障转移。

（1）在master上执行备份（192.168.134.191）

 mysqldump -A -B --master-data=2 --events > all.sql

--master-data[=#]：此选项须启用二进制日志 1：所备份的数据之前加一条记录为CHANGE MASTER TO语句，非注释，不指定#，默认为1 2：记录为注释的CHANGE MASTER TO语句 --events：备份相关的所有event scheduler

（2）在server02上创建复制用户：

mysql>grant all on *.* to [email protected]‘192.168.134.%‘ identified by ‘centos‘; 监控用户

mysql>grant replication slave on *.* to [email protected]‘192.168.134.%‘ identified by ‘centos‘; 复制用户

（3）查看主库备份时的binlog名称和位置，MASTER_LOG_FILE和MASTER_LOG_POS：

MariaDB [(none)]> show master logs;
+--------------------+-----------+
| Log_name           | File_size |
+--------------------+-----------+
| mariadb-bin.000001 |      8749 |
| mariadb-bin.000002 |       245 |
+--------------------+-----------+

（4）把备份复制到slave1和slave2

scp all.sql 192.168.134.2：
scp all.sql 192.168.134.194：

（5）导入all.sql

mysql < all.sql

mysql > CHANGE MASTER TO
  MASTER_HOST=‘192.168.134.193‘,
  MASTER_USER=‘repluser‘,
  MASTER_PASSWORD=‘centos‘,
  MASTER_PORT=3306,
  MASTER_LOG_FILE=‘mariadb-bin.000002‘,
  MASTER_LOG_POS=245;

查看状态MariaDB [(none)]> show slave statusG;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.134.193
                  Master_User: repluser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000002
          Read_Master_Log_Pos: 245
               Relay_Log_File: mariadb-relay-bin.000002
                Relay_Log_Pos: 531
        Relay_Master_Log_File: mariadb-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

（6）两台slave服务器设置read_only（从库对外提供读服务，只所以没有写进配置文件，是因为随时slave会提升为master）

vim /etc/my.cnf
[mysqld]
skip_name_resolve    禁止主机名解析，建议使用
innodb_file_per_table 可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。
read_only
relay_log_purge=0    MHA可通过purge_relay_logs禁用自动删除功能以及定期清理
server_id=3
log_bin

4.配置MHA

（1）创建MHA的工作目录，并且创建相关配置文件（在软件包解压后的目录里面有样例配置文件）。

[server default]
user=mhauser
password=centos
manager_workdir=/data/mastermha/app1/ //设置manager的工作目录
manager_log=/data/mastermha/app1/manager.log   //设置manager的日志
remote_workdir=/data/mastermha/app1/   //设置master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
ssh_user=root                           //设置ssh的登录用户名
repl_user=repluser                      //设置复制环境中的复制用户名
repl_password=centos //设置复制环境中的密码
ping_interval=1        //设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
[server1]
hostname=192.168.134.193
candidate_master=1
[server2]
hostname=192.168.134.2
candidate_master=1   //设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
[server3]
hostname=192.168.134.194

注意：

MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）

5.检查SSH配置

检查MHA Manger到所有MHA Node的SSH连接状态：

[[email protected] ~]# masterha_check_ssh --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:02:58 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:02:58 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:02:58 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:02:58 2018 - [info] Starting SSH connection tests..
Mon Aug  6 18:03:01 2018 - [debug]
Mon Aug  6 18:02:59 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.194:22) to [email protected](192.168.134.193:22)..
Mon Aug  6 18:03:00 2018 - [debug]   ok.
Mon Aug  6 18:03:00 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.194:22) to [email protected](192.168.134.2:22)..
Mon Aug  6 18:03:01 2018 - [debug]   ok.
Mon Aug  6 18:03:06 2018 - [debug]
Mon Aug  6 18:02:58 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.2:22) to [email protected](192.168.134.193:22)..
Mon Aug  6 18:03:04 2018 - [debug]   ok.
Mon Aug  6 18:03:04 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.2:22) to [email protected](192.168.134.194:22)..
Warning: Permanently added ‘192.168.134.194‘ (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:05 2018 - [debug]   ok.
Mon Aug  6 18:03:10 2018 - [debug]
Mon Aug  6 18:02:58 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.193:22) to [email protected](192.168.134.2:22)..
Warning: Permanently added ‘192.168.134.2‘ (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:09 2018 - [debug]   ok.
Mon Aug  6 18:03:09 2018 - [debug]  Connecting via SSH from [email protected](192.168.134.193:22) to [email protected](192.168.134.194:22)..
Warning: Permanently added ‘192.168.134.194‘ (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:10 2018 - [debug]   ok.
Mon Aug  6 18:03:10 2018 - [info] All SSH connection tests passed successfully.

6.检查整个复制环境状况。

[[email protected] ~]# masterha_check_repl --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:11:54 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:11:54 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:11:54 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:11:54 2018 - [info] MHA::MasterMonitor version 0.56.
Mon Aug  6 18:11:55 2018 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln671] Master 192.168.134.191:3306 from which slave 192.168.134.193(192.168.134.193:3306) replicates is not defined in the configuration file!
Mon Aug  6 18:11:55 2018 - [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 326.
Mon Aug  6 18:11:55 2018 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Mon Aug  6 18:11:55 2018 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!
[[email protected] ~]# masterha_check_repl --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:13:27 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:13:27 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:13:27 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:13:27 2018 - [info] MHA::MasterMonitor version 0.56.
Mon Aug  6 18:13:29 2018 - [info] GTID failover mode = 0
Mon Aug  6 18:13:29 2018 - [info] Dead Servers:
Mon Aug  6 18:13:29 2018 - [info] Alive Servers:
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.2(192.168.134.2:3306)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.194(192.168.134.194:3306)
Mon Aug  6 18:13:29 2018 - [info] Alive Slaves:
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.2(192.168.134.2:3306)  Version=5.5.56-MariaDB (oldest major version between slaves) log-bin:enabled
Mon Aug  6 18:13:29 2018 - [info]     Replicating from 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.194(192.168.134.194:3306)  Version=5.5.56-MariaDB (oldest major version between slaves) log-bin:enabled
Mon Aug  6 18:13:29 2018 - [info]     Replicating from 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info] Current Alive Master: 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info] Checking slave configurations..
Mon Aug  6 18:13:29 2018 - [info] Checking replication filtering settings..
Mon Aug  6 18:13:29 2018 - [info]  binlog_do_db= , binlog_ignore_db=
Mon Aug  6 18:13:29 2018 - [info]  Replication filtering check ok.
Mon Aug  6 18:13:29 2018 - [info] GTID (with auto-pos) is not supported
Mon Aug  6 18:13:29 2018 - [info] Starting SSH connection tests..
Mon Aug  6 18:13:47 2018 - [info] All SSH connection tests passed successfully.
Mon Aug  6 18:13:47 2018 - [info] Checking MHA Node version..
Mon Aug  6 18:13:49 2018 - [info]  Version check ok.
Mon Aug  6 18:13:49 2018 - [info] Checking SSH publickey authentication settings on the current master..
Mon Aug  6 18:13:49 2018 - [info] HealthCheck: SSH to 192.168.134.193 is reachable.
Mon Aug  6 18:13:50 2018 - [info] Master MHA Node version is 0.56.
Mon Aug  6 18:13:50 2018 - [info] Checking recovery script configurations on 192.168.134.193(192.168.134.193:3306)..
Mon Aug  6 18:13:50 2018 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/data/mastermha/app1//save_binary_logs_test --manager_version=0.56 --start_file=mariadb-bin.000001
Mon Aug  6 18:13:50 2018 - [info]   Connecting to [email protected](192.168.134.193:22)..
  Creating /data/mastermha/app1 if not exists.. Creating directory /data/mastermha/app1.. done.
   ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to mariadb-bin.000001
Mon Aug  6 18:13:50 2018 - [info] Binlog setting check done.
Mon Aug  6 18:13:50 2018 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Mon Aug  6 18:13:50 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=‘mhauser‘ --slave_host=192.168.134.2 --slave_ip=192.168.134.2 --slave_port=3306 --workdir=/data/mastermha/app1/ --target_version=5.5.56-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Aug  6 18:13:50 2018 - [info]   Connecting to [email protected](192.168.134.2:22)..
Creating directory /data/mastermha/app1/.. done.
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to mariadb-relay-bin.000002
    Temporary relay log file is /var/lib/mysql/mariadb-relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Aug  6 18:13:56 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=‘mhauser‘ --slave_host=192.168.134.194 --slave_ip=192.168.134.194 --slave_port=3306 --workdir=/data/mastermha/app1/ --target_version=5.5.56-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Aug  6 18:13:56 2018 - [info]   Connecting to [email protected](192.168.134.194:22)..
Creating directory /data/mastermha/app1/.. done.
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to mariadb-relay-bin.000002
    Temporary relay log file is /var/lib/mysql/mariadb-relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Aug  6 18:13:56 2018 - [info] Slaves settings check done.
Mon Aug  6 18:13:56 2018 - [info]
192.168.134.193(192.168.134.193:3306) (current master)
 +--192.168.134.2(192.168.134.2:3306)
 +--192.168.134.194(192.168.134.194:3306)

Mon Aug  6 18:13:56 2018 - [info] Checking replication health on 192.168.134.2..
Mon Aug  6 18:13:56 2018 - [info]  ok.
Mon Aug  6 18:13:56 2018 - [info] Checking replication health on 192.168.134.194..
Mon Aug  6 18:13:56 2018 - [info]  ok.
Mon Aug  6 18:13:56 2018 - [warning] master_ip_failover_script is not defined.
Mon Aug  6 18:13:56 2018 - [warning] shutdown_script is not defined.
Mon Aug  6 18:13:56 2018 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

7.检查MHA Manager的状态：

通过master_check_status脚本查看Manager的状态：

[[email protected] ~]# masterha_manager --conf=/etc/mastermha/app1.cnf
Mon Aug  6 19:10:08 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 19:10:08 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 19:10:08 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
  Creating /data/mastermha/app1 if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to mariadb-bin.000001

以上是关于LAMP架构之9——MySQL高可用切换(MHA)的主要内容，如果未能解决你的问题，请参考以下文章

MySQL高可用架构之MHA

Mysql实现高可用架构之MHA