MySQL数据库高可用之MHA

一、高可用集群

MySQL服务的主从和互主以及半同步集群，都是使用MySQL自身的功能来搭建的集群。但是这样的集群，不具备高可用的功能。即如果是MySQL主服务挂了，从服务是没办法自动切换成主服务的。而如果要实现MySQL的高可用，需要借助一些第三方工具来实现。

1.1 集群的主要类型

高可用集群（High Available Cluster，HA Cluster）

高可用集群是指通过特殊的软件把独立的服务器连接起来，组成一个能够提供故障切换（Fail Over）功能的集群
负载均衡集群
高性能集群

1.2 如何衡量高可用

可用性级别(指标)	年度宕机时间	描述	叫法
99%	3.65天/年	基本可用系统	2个9
99.9%	8.76小时/年	可用系统	3个9
99.99%	52.6分钟/年	高可用系统	4个9
99.999%	5.3分钟/年	抗故障系统	5个9
99.9999%	32秒/年	容错系统	6个9

计算方法：

1年 = 365天 = 8760小时
99% = 8760 * 1% = 8760 * 0.01 = 87.6小时=3.65天
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

1.3 MySQL 高可用解决方案

MySQL官方和社区里推出了很多高可用的解决方案，大体如下，仅供参考（数据引用自Percona）

MMM: Multi-Master Replication Manager for MySQL，Mysql主主复制管理器是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql MasterMaster复制的配置(同一时间只有一个节点是可写的)。
官网：http://www.mysql-mmm.org https://code.google.com/archive/p/mysql-master-master/downloads
MHA：Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，出于机器成本的考虑，淘宝进行了改造，目前淘宝TMHA已经支持一主一从。官方网站：https://code.google.com/archive/p/mysql-master-ha/ https://github.com/yoshinorim/mha4mysql-manager/releases https://github.com/yoshinorim/mha4mysql-node/releases/tag/v0.58
Galera Cluster：wsrep(MySQL extended with the Write Set Replication)通过wsrep协议在全局实现复制；任何一节点都可读写，不需要主从复制，实现多主读写。
GR（Group Replication）：MySQL官方提供的组复制技术(MySQL 5.7.17引入的技术)，基于原生复制技术Paxos算法，实现了多主更新，复制组由多个server成员构成，组中的每个server可独立地执行事务，但所有读写事务只在冲突检测成功后才会提交。

这3个节点互相通信，每当有事件发生，都会向其他节点传播该事件，然后协商，如果大多数节点都同意这次的事件，那么该事件将通过，否则该事件将失败或回滚。这些节点可以是单主模型的(single-primary)，也可以是多主模型的(multi-primary)。单主模型只有一个主节点可以接受写操作，主节点故障时可以自动选举主节点。多主模型下，所有节点都可以接受写操作，所以没有master-slave的概念。

二、MHA

2.1 什么是MHA？

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

2.2 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 适合任何存储引擎, 只要能主从复制的存储引擎它都支持，不限于支持事物的 innodb 引擎。

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

(图1)

2.3 故障切换过程

1）从宕机崩溃的master保存二进制日志事件（binlog events）;
2）识别含有最新更新的slave；
3）应用差异的中继日志（relay log）到其他的slave；
4）应用从master保存的二进制日志事件（binlog events）；
5）提升一个slave为新的master；
6）使其他的slave连接新的master进行复制；

2.4 MHA软件的组成部分

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半同步复制。

三、部署MHA

3.1 环境要求

将服务器的防火墙和selinux关闭

3.2 配置环境

IP	角色	软件
192.168.1.101	manager	mha4mysql-manager、mha4mysql-node
192.168.1.102	master	mha4mysql-node
192.168.1.103	slave01，备选Master	mha4mysql-node
192.168.1.104	slave02	mha4mysql-node

其中master对外提供写服务，备选Candicate master（实际为slave1）提供读服务，slave2也提供读服务，一旦master宕机，将会把备选master提升为新的master，slave指向新的master

3.3 部署MHA

在所有节点安装MHA node所需的perl模块（DBD:mysql），安装脚本如下

先要安装epel源
yum -y install epel-release
yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager --skip-broken

2）上传MHA相关包，在所有的节点安装mha-node

[root@manager mha4mysql-0.57]# ls
mha4mysql-manager-0.57-0.el7.noarch.rpm  mha4mysql-manager-0.57.tar.gz  mha4mysql-node-0.57-0.el7.noarch.rpm  mha4mysql-node-0.57.tar.gz
[root@manager mha4mysql-0.57]# rpm -ivh mha4mysql-node-0.57-0.el7.noarch.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:mha4mysql-node-0.57-0.el7        ################################# [100%]

安装完成后会在/usr/bin/目录下生成以下脚本文件

[root@manager bin]# pwd
/usr/bin
[root@manager bin]# ll app* filter* purge* save*
-rwxr-xr-x 1 root root 16381 May 31  2015 apply_diff_relay_logs
-rwxr-xr-x 1 root root  4807 May 31  2015 filter_mysqlbinlog
-rwxr-xr-x 1 root root  8261 May 31  2015 purge_relay_logs
-rwxr-xr-x 1 root root  7525 May 31  2015 save_binary_logs

3.3.1 安装MHA Manager

MHA Manager中主要包括了几个管理员的命令行工具，例如master_manger，master_master_switch等。MHA Manger也依赖于perl模块，具体如下：

3.3.1.1 安装MHA Node软件包之前需要安装依赖

我这里使用yum完成，首先epel源要安装。

注意：刚才我们已经配置epel源。

[root@manager ~]# yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN -y

3.3.1.2 安装MHA Manager

首先安装MHA Manger依赖的perl模块（已经使用yum安装）

[root@manager mha4mysql-0.57]# rpm -ivh mha4mysql-manager-0.57-0.el7.noarch.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:mha4mysql-manager-0.57-0.el7     ################################# [100%]

安装完成后会在/usr/bin目录下面生成以下脚本文件

[root@manager mha4mysql-0.57]# ll /usr/bin/mast*
-rwxr-xr-x 1 root root 1995 May 31  2015 /usr/bin/masterha_check_repl
-rwxr-xr-x 1 root root 1779 May 31  2015 /usr/bin/masterha_check_ssh
-rwxr-xr-x 1 root root 1865 May 31  2015 /usr/bin/masterha_check_status
-rwxr-xr-x 1 root root 3201 May 31  2015 /usr/bin/masterha_conf_host
-rwxr-xr-x 1 root root 2517 May 31  2015 /usr/bin/masterha_manager
-rwxr-xr-x 1 root root 2165 May 31  2015 /usr/bin/masterha_master_monitor
-rwxr-xr-x 1 root root 2373 May 31  2015 /usr/bin/masterha_master_switch
-rwxr-xr-x 1 root root 5171 May 31  2015 /usr/bin/masterha_secondary_check
-rwxr-xr-x 1 root root 1739 May 31  2015 /usr/bin/masterha_stop

3.3.2 配置所有主机相互SSH登录无密码验证

注意：不能禁止 password 登陆，否则会出现错误

[root@manager ~]# ssh-keygen -t rsa
[root@manager ~]# ssh-copy-id 192.168.1.102
[root@manager ~]# ssh-copy-id 192.168.1.103
[root@manager ~]# ssh-copy-id 192.168.1.104
其他主机也是一样操作。

3.3.3 配置主数据库

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

3.3.3.1 在master配置主数据库服务器

[root@master ~]# ~]# wget -i -c http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm
  ##使用上面的命令就直接下载了安装用的Yum Repository，大概25KB的样子，然后就可以直接yum安装了。

[root@master ~]# yum -y install mysql57-community-release-el7-10.noarch.rpm
  ##之后就开始安装MySQL服务器。

[root@master ~]# yum -y install mysql-community-server 
  ##这步可能会花些时间，安装完成后就会覆盖掉之前的mariadb。

3.3.3.2 使用临时密码登录数据库

mysql> set global validate_password_policy=0;
mysql> set global validate_password_length=6;
mysql> set password for 'root'@'localhost'=password('123456');

3.3.3.3 创建需要同步的数据库

mysql> create database HA;
mysql> use HA;
mysql> create table test(id int,name varchar(20));

3.3.3.4 配置mysql

log-bin=mysql-bin-master  #启用二进制日志
server-id=1   #本机数据库ID 标示
binlog-do-db=HA #可以被从服务器复制的库。二进制需要同步的数据库名
binlog-ignore-db=mysql  #不可以被从服务器复制的库
validate-password=off

3.3.3.5 重启数据库

[root@master ~]# systemctl restart mysqld

3.3.3.6 授权连接账号

授权给另外2个从数据库权限，使其可以来同步数据库数据

mysql> grant replication slave on *.* to repl@'192.168.1.%' identified by '123456';

mysql> flush privileges;

3.3.3.7 将HA数据库导出，并导入到另外两个从库

[root@master ~]# mysqldump  -uroot -p123456 -B HA >HA.sql
[root@master ~]# scp HA.sql 192.168.1.103:/root  
[root@master ~]# scp HA.sql 192.168.1.104:/root

3.3.4 配置slave1

3.3.4.1 导入数据库

mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)

mysql> set global validate_password_length=6;
Query OK, 0 rows affected (0.00 sec)

mysql> set password for 'root'@'localhost'=password('123456');
Query OK, 0 rows affected, 1 warning (0.00 sec)


[root@slave01 ~]# mysql -uroot -p123456 <HA.sql
mysql: [Warning] Using a password on the command line interface can be insecure.

3.3.4.2 配置mysql

log-bin=mysql-slave1  #启用二进制日志
server-id=2   #本机数据库ID 标示
binlog-do-db=HA #可以被从服务器复制的库。二进制需要同步的数据库名
binlog-ignore-db=mysql  #不可以被从服务器复制的库
log_slave_updates=1 #只有开启log_slave_updates，从库binlog才会记录主库同步的操作日志
validate-password=off

3.3.4.3 重启mysql

[root@slave01 ~]# systemctl restart mysqld

3.3.4.4 授权

mysql> grant replication slave on *.* to 'repl'@'192.168.1.%' identified by '123456';

mysql> flush privileges;

3.3.4.5 指定主服务器的IP地址

mysql> stop slave;

mysql> change master to master_host='192.168.1.102',master_user='repl',master_password='123456';

mysql> start slave;

3.3.5 配置slave02

3.3.5.1 导入数据库

mysql> set global validate_password_policy=0;

mysql> set global validate_password_length=6;

mysql> set password for 'root'@'localhost'=password('123456');

[root@slave02 ~]# mysql -uroot -p123456 <HA.sql

3.3.5.2 配置mysql

log-bin=mysql-slave2  #启用二进制日志
server-id=3          #本机数据库ID 标示
binlog-do-db=HA      #可以被从服务器复制的库。二进制需要同步的数据库名
binlog-ignore-db=mysql  #不可以被从服务器复制的库
log_slave_updates=1 #只有开启log_slave_updates，从库binlog才会记录主库同步的操作日志
validate-password=off

3.3.5.3 重启数据库

[root@slave02 ~]# systemctl restart mysqld

3.3.5.4 授权

mysql> grant replication slave on *.* to repl@'192.168.1.%' identified by '123456';

mysql> flush privileges;

3.3.5.5 指定主服务器的IP地址

mysql> stop slave;

mysql> change master to master_host='192.168.1.102',master_user='repl',master_password='123456';

mysql> start slave;

3.3.6 两台slave服务器设置read_only

（从库对外提供读服务，之所以没有写进配置文件，是因为slave随时会提升为master）

[root@slave01 ~]# mysql -uroot -p123456 -e 'set global read_only=1'
[root@slave02 ~]# mysql -uroot -p123456 -e 'set global read_only=1'

3.3.7 创建监控用户（在master上执行）

mysql>  grant all privileges on *.* to 'root'@'192.168.1.%' identified  by '123456';

mysql> flush  privileges;

到这里整个集群环境已经搭建完毕，剩下的就是配置MHA软件了。

3.3.8 配置MHA

3.3.8.1 创建MHA的工作目录，并且创建相关配置文件

[root@manager ~]# mkdir -p /etc/masterha
[root@manager ~]# mkdir -p /var/log/masterha/app1

[root@manager ~]#  vim  /etc/masterha/app1.cnf
# 修改app1.cnf配置文件，修改后的文件内容如下（注意，配置文件中的注释需要去掉）

[server default]
manager_workdir=/var/log/masterha/app1            #设置manager的工作目录
manager_log=/var/log/masterha/app1/manager.log    #设置manager的日志
master_binlog_dir=/var/lib/mysql                  #设置master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
master_ip_failover_script= /usr/local/bin/master_ip_failover    #设置自动failover时候的切换脚本
master_ip_online_change_script= /usr/local/bin/master_ip_online_change  #设置手动切换时候的切换脚本
password=123456         #设置mysql中root用户的密码，这个密码是前文中创建监控用户的那个密码
user=root               #设置监控用户root
ping_interval=1         #设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
remote_workdir=/tmp     #设置远端mysql在发生切换时binlog的保存位置
repl_password=123456    #设置复制用户的密码
repl_user=repl          #设置复制环境中的复制用户名
report_script=/usr/local/send_report    #设置发生切换后发送的报警的脚本
shutdown_script=""      #设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）
ssh_user=root           #设置ssh的登录用户名

[server1]
hostname=192.168.1.102
port=3306

[server2]
hostname=192.168.1.103
port=3306
candidate_master=1   #设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
check_repl_delay=0   #默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

[server3]
hostname=192.168.1.104
port=3306

3.3.8.2 设置relay log的清除方式（在每个slave节点上）

[root@slave01 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'
[root@slave02 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'

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

3.3.8.3 检查SSH配置

[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf 
Thu Nov 25 22:18:04 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Nov 25 22:18:04 2021 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Thu Nov 25 22:18:04 2021 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Thu Nov 25 22:18:04 2021 - [info] Starting SSH connection tests..
Thu Nov 25 22:18:05 2021 - [debug] 
Thu Nov 25 22:18:04 2021 - [debug]  Connecting via SSH from root@192.168.1.102(192.168.1.102:22) to root@192.168.1.103(192.168.1.103:22)..
Thu Nov 25 22:18:04 2021 - [debug]   ok.
Thu Nov 25 22:18:04 2021 - [debug]  Connecting via SSH from root@192.168.1.102(192.168.1.102:22) to root@192.168.1.104(192.168.1.104:22)..
Thu Nov 25 22:18:05 2021 - [debug]   ok.
Thu Nov 25 22:18:06 2021 - [debug] 
Thu Nov 25 22:18:05 2021 - [debug]  Connecting via SSH from root@192.168.1.103(192.168.1.103:22) to root@192.168.1.102(192.168.1.102:22)..
Thu Nov 25 22:18:05 2021 - [debug]   ok.
Thu Nov 25 22:18:05 2021 - [debug]  Connecting via SSH from root@192.168.1.103(192.168.1.103:22) to root@192.168.1.104(192.168.1.104:22)..
Thu Nov 25 22:18:05 2021 - [debug]   ok.
Thu Nov 25 22:18:07 2021 - [debug] 
Thu Nov 25 22:18:05 2021 - [debug]  Connecting via SSH from root@192.168.1.104(192.168.1.104:22) to root@192.168.1.102(192.168.1.102:22)..
Thu Nov 25 22:18:05 2021 - [debug]   ok.
Thu Nov 25 22:18:05 2021 - [debug]  Connecting via SSH from root@192.168.1.104(192.168.1.104:22) to root@192.168.1.103(192.168.1.103:22)..
Thu Nov 25 22:18:06 2021 - [debug]   ok.
Thu Nov 25 22:18:07 2021 - [info] All SSH connection tests passed successfully.

扩展：如下报错，请检查一下你的4台主机是否全部做了节点互信，需要全部都做。

3.3.8.4 检查整个复制环境状况

通过masterha_check_repl脚本查看整个集群的状态

[root@manager ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf
Fri Nov 26 09:14:54 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Nov 26 09:14:54 2021 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Fri Nov 26 09:14:54 2021 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Fri Nov 26 09:14:54 2021 - [info] MHA::MasterMonitor version 0.57.
Fri Nov 26 09:14:55 2021 - [info] GTID failover mode = 0
Fri Nov 26 09:14:55 2021 - [info] Dead Servers:
Fri Nov 26 09:14:55 2021 - [info] Alive Servers:
Fri Nov 26 09:14:55 2021 - [info]   192.168.1.102(192.168.1.102:3306)
Fri Nov 26 09:14:55 2021 - [info]   192.168.1.103(192.168.1.103:3306)
Fri Nov 26 09:14:55 2021 - [info]   192.168.1.104(192.168.1.104:3306)
Fri Nov 26 09:14:55 2021 - [info] Alive Slaves:
......
Fri Nov 26 09:15:03 2021 - [info] Checking replication health on 192.168.1.103..
Fri Nov 26 09:15:03 2021 - [info]  ok.
Fri Nov 26 09:15:03 2021 - [info] Checking replication health on 192.168.1.104..
Fri Nov 26 09:15:03 2021 - [info]  ok.
Fri Nov 26 09:15:03 2021 - [info] Checking master_ip_failover_script status:
Fri Nov 26 09:15:03 2021 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.1.102 --orig_master_ip=192.168.1.102 --orig_master_port=3306 
Fri Nov 26 09:15:03 2021 - [info]  OK.
Fri Nov 26 09:15:03 2021 - [warning] shutdown_script is not defined.
Fri Nov 26 09:15:03 2021 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.   ##如果状态是OK的，则代表是没有问题。

扩展：这里列出几个常见的错误：

1、如下报错，是因为我们在mha中指定的master_binlog_dir的路径在master这边找不到/data/mysql这个路径，需要修改成默认的路径（/var/lib/mysql---yum安装的路径）

2、如下报错，是因为我们的mha配置文件中没有“/usr/local/bin/master_ip_failover”这个文件，需要先创建，然后再给定执行权限。

[root@manager ~]# touch /usr/local/bin/master_ip_failover
[root@manager ~]# chmod 755 /usr/local/bin/master_ip_failover

3.3.8.5 检查MHA Manager的状态

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

[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

注意：如果正常，会显示"PING_OK"，否则会显示"NOT_RUNNING"，这代表MHA监控没有开启。

3.3.8.6 开启MHA Manager监控

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &  
[1] 16950


再次查看状态
[root@manager app1]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:17420) is running(0:PING_OK), master:192.168.1.102

启动参数介绍：

--remove_dead_master_conf   该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。

--manger_log         日志存放位置

--ignore_last_failover      在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。

可以看到已经处于监控了，而且主服务器是192.168.1.102.

3.3.8.7 关闭MHA Manager监控

[root@manager app1]# masterha_stop --conf=/etc/masterha/app1.cnf
Stopped app1 successfully.
[1]+  Exit 1                  nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1

注意：启动MHA的Manager再进行故障模拟

3.3.8.8 模拟故障

1）先打开一个会话，监控状态

[root@manager ~]# tail -f /var/log/masterha/app1/manager.log

2）停止主数据库（192.168.1.102），看是否有切换

[root@master mysql]# systemctl stop mysqld

3）查看日志发现，主数据库已经切换到了192.168.1.103

Fri Nov 26 09:46:57 2021 - [info] Checking master_ip_failover_script status:
Fri Nov 26 09:46:57 2021 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.1.103 --orig_master_ip=192.168.1.103 --orig_master_port=3306 
Fri Nov 26 09:46:57 2021 - [info]  OK.
Fri Nov 26 09:46:57 2021 - [warning] shutdown_script is not defined.
Fri Nov 26 09:46:57 2021 - [info] Set master ping interval 1 seconds.
Fri Nov 26 09:46:57 2021 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Fri Nov 26 09:46:57 2021 - [info] Starting ping health check on 192.168.1.103(192.168.1.103:3306)..
Fri Nov 26 09:46:57 2021 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

4）查看slave02，发现主服务器也已经切换到了192.168.1.103

当 master down机后,mha自动退出

[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

四、总结

目前高可用方案可以一定程度上实现数据库的高可用，还有其他方案heartbeat+drbd，Cluster等。这些高可用软件各有优劣。在进行高可用方案选择时，主要是看业务还有对数据一致性方面的要求。最后出于对数据库的高可用和数据一致性的要求，推荐使用MHA架构。