关注我「程序猿集锦」，获取更多分享。

• 前言
• 创建MySQL主从复制集群
• 准备MySQL数据库环境
• 配置主从链路
• 启动主从复制
• 安装MHA
• 下载MHA
• 安装MHA
• 配置ssh免密登录
• 安装MAH软件包
• 配置MHA
• 验证MHA配置
• 启动MHA
• MHA命令介绍
• mah-manager命令
• mha-node命令
• mah-自定义脚本
• 主从切换的验证
• 监控manager节点的日志
• 停止master1节点
• 验证主从切换结果
• 恢复master1节点
• 再次启动MHA服务

前言

上一篇文章中，我们分享是MySQL高可用集群实现的方式之一：MMM高可用集群。这是一种比较老的高可用集群实现方式。今天我们来看另外一种MySQL高可用集群的实现方式，MHA(Master High Availability)。

最简单一个MHA网络拓扑如下所示，它不像MMM架构那样可以支持两个Master节点，它支持有一个master节点主从复制集群。

创建MySQL主从复制集群

准备MySQL数据库环境

使用如下命令，创建一个docker虚拟网段，这个网段仅用于当前MySQL安装MHA集群来使用。便于归类管理。

docker network create --subnet=172.21.0.0/24 mysql-ha-mha-network

启动三个MySQL数据库示例，分别是master1、slave1、slave2，用于搭建一主两从的MySQL集群。

# master1节点
docker run --net=mysql-ha-mha-network --hostname master1.mysql --ip 172.21.0.11 --cap-add NET_ADMIN --name mysql-ha-mha-master1 -d -v /Users/coder-home/docker_mysql_ha/mha/master1:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33011:3306 mysql:5.7.31

# slave1节点
docker run --net=mysql-ha-mha-network --hostname slave1.mysql --ip 172.21.0.12 --cap-add NET_ADMIN --name mysql-ha-mha-slave1 -d -v /Users/coder-home/docker_mysql_ha/mha/slave1:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33012:3306 mysql:5.7.31

# slave2节点
docker run --net=mysql-ha-mha-network --hostname slave2.mysql --ip 172.21.0.22 --cap-add NET_ADMIN --name mysql-ha-mha-slave2 -d -v /Users/coder-home/docker_mysql_ha/mha/slave2:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33022:3306 mysql:5.7.31

除了上面的三个MySQL节点之外，MHA架构还需要一台服务器用于部署MHA的监控服务，当然也可以把这个MHA监控服务器安装在某一个MySQL节点上。我们这里在单独运行一个MySQL容器，用于部署MHA服务。这个MySQL容器，只是用于部署MHA监控服务，不参与其他功能，所以我们挂载MySQL配置my.cnf配置文件了。

# MHA的管理节点
docker run --net=mysql-ha-mha-network --hostname manager.mysql --ip 172.21.0.100 --cap-add NET_ADMIN --name mysql-ha-mha-manager -d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" mysql:5.7.31

配置主从链路

我们是一个展现的MySQL集群，不涉及到历史数据的同步，所以在MySQL的三个节点启动成功之后，只要在slave1和slave2上面配置一下主从同步的链路，然后启动主从复制的链路就可以了。

查看master1节点的日志点

mysql> show master status;
+--------------------------+----------+--------------+------------------+-------------------+
| File                     | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+--------------------------+----------+--------------+------------------+-------------------+
| master1-mysql-bin.000001 |      154 |              |                  |                   |
+--------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

在两个从节点上，都执行如下命令，用于配置主从链路。

change master to master_user='repl', master_password='repl', master_host='172.21.0.11', master_log_file='master1-mysql-bin.000001', master_log_pos=154;

在主节点上面，执行如下命令，用于创建主从复制链路使用的MySQL数据库用户。

create user 'repl'@'172.21.0.%' identified by 'repl';
grant replication client, replication slave on *.* to 'repl'@'172.21.0.%';
/* 这里之所有增加replication client的原因是，这个账号会同步到所有的slave节点，任何一个从节点，在主宕机的时候，都可能成功主，这样做是为了避免以后的权限不足导致主从切换失败。 */

启动主从复制

在两个从节点，执行如下命令，来启动主从复制链路。

start slave;

在slave上执行如下命令，查看主从同步的状态

show slave status\G

如果你对如何配置组从复制集群不了解，可以参考我分享的历史文章。

注意：这里的MySQL集群使用的是基于日志点的复制来实现的，如果使用基于GTID的复制方式也是可以的。

安装MHA

下载MHA

如果是要使用源码编译安装，源码下载的地址有2个地方，一个是Google，另外一个是GitHub。

从Google网站上下载，需要特殊的方式才可以下载，请自备梯子。地址为：https://code.google.com/archive/p/mysql-master-ha/downloads。这里下载的是稳定版本，最近的一个版本是0.55版本。

另外一个下载的地方是GitHub，这里有比较新的版本，如果你想要更新的版本，可以从这里下载。下载地址为：https://github.com/yoshinorim/mha4mysql-manager，目前这里最新的版本是0.58版本。

以上两个下载的地方，除了可以提供源码下载之外，还可以提供试用Linux、CentOS的rpm安装包和使用Debian、Ubuntu的deb安装包。如果你不想使用源码编译安装，那么下载对应的rpm文件和deb文件也是可以的。

我这里使用apt-get来安装，这样的方式也是基于deb文件来安装的，但是它可以自己解决安装MHA的deb安装的依赖文件，不用先安装依赖了。

安装MHA

在下载安装之前，先配置一下apt-get源，然后安装一下常用的工具包软件。

cp /etc/apt/sources.list /etc/apt/sources.list.bak

echo "
deb http://mirrors.aliyun.com/debian/ buster main non-free contrib
deb http://mirrors.aliyun.com/debian-security buster/updates main
deb http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib
deb http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib

deb-src http://mirrors.aliyun.com/debian-security buster/updates main
deb-src http://mirrors.aliyun.com/debian/ buster main non-free contrib
deb-src http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib
deb-src http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib
" > /etc/apt/sources.list

更新系统，并安装常用的软件包：

# 更新系统
apt-get update

# 安装常用软件包
apt-get install net-tools vim ssh telnet iproute2 iproute2-doc -y

配置ssh免密登录

在MySQL集群中，需要配合各个节点之间的免密登录，因为MHA在做主从切换故障转移的时候，需要依赖于ssh免密登录的功能。

用操作系统的root用户在每一个节点上面都执行如下命令，一路回车就行

# 创建公钥和私钥，一路回车默认即可
ssh-keygen

# 启动ssh服务
/etc/init.d/ssh start

# 把公钥配置到各个节点的`~/.ssh/authorized_keys`配置文件中
ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.21.0.11
ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.21.0.12
ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.21.0.22
ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.21.0.100

修改所有节点的host文件，在host文件中增加IP地址和主机名称的映射关系如下，便于在使用ssh命令的时候，通过主机名称来连接。

# 修改所有节点的host文件
vim /etc/hosts

# host文件增加如下内容
172.21.0.11	master1.mysql master1
172.21.0.12	slave1.mysql slave1
172.21.0.22	slave2.mysql slave2
172.21.0.100	manager.mysql manager

备注：方便以后使用，可以配置ssh服务开机自动启动：

systemctl ssh enable

安装MAH软件包

我们可以使用apt-get的方式来安装，也可以使用源码来编译安装。如果是用源码编译安装，需要提前手动安装一些编译所依赖的软件包。如果使用apt-get则可以避免手动安装依赖，apt-get会自动下载并安装所有MAH软件依赖的软件包。如果你使用的服务器不是Ubuntu，而是RedHat或者CentOS，可以使用yum来安装，而不是这里提到的apt-get。

# 查看mha安装包
apt-cache search mha4mysql

# 所有的node节点执行如下命令，包括manager节点
apt-get install mha4mysql-node -y

# 在manager节点执行如下命令
apt-get install mha4mysql-manager -y

注意：截止目前为止，上面命令安装的MHA的版本是0.58，随着时间的推移如果你也采用上面的apt-get来安装，可能安装的版本会比这个更新。后面的配置也是基于这个版本来操作的。

配置MHA

配置文件目录自定义，文件自己写，可以从GitHub上下载的安装包中查找示例。

建议配置文件放在/etc/mha下面。这个目录不存在可以使用操作系统的root用户来创建。

# 下面这个目录用于存放mha的配置文件
mkdir -p /etc/mha

# 下面的目录用于存放自定义的Perl脚本
mkdir -p /etc/mha/aap1

在/etc/mha下面创建一个app1.cnf配置文件，表示一个MySQL集群的配置文件，如果有多个MySQL集群需要做MHA的监控，这里可以创建多个app.cnf配置文件。

root@manager:/etc/mha# cat /etc/mha/app1.cnf

[server default]

# manager服务在manger节点的工作目录，这里会生成一些临时文件
manager_workdir=/var/log/mha/app1

# node服务在node节点的工作目录，这里会生成一些临时文件，主要用来保存从已经宕机的主节点上保存下来的binglog日志文件
remote_workdir=/var/log/mha/app1

# manager服务运行过程中日志文件
manager_log=/var/log/mha/app1/app1.log

# 备选主节点的健康状态监测的命令
secondary_check_script=masterha_secondary_check -s 172.21.0.12

# master节点在宕机的时候，执行切换的时候，执行的自定义脚本文件，可以不指定配置这个脚本，如果想在切换的时候，实现自己的逻辑，可以在这里进行编写。比如编写VIP漂移的逻辑等
master_ip_failover_script=/etc/mha/app1/master_ip_failover

#shutdown_script=/etc/mha/app1/power_manager

# 发生主从切换之后，发送邮件通知运维人员的自定义脚本
#report_script=/etc/mha/app1/send_master_failover_mail


# MySQL的root用户账号和密码
user=root
password=root

# 服务器中配置ssh免密登录的用户
ssh_user=root

# MySQL组从同步复制的用户和密码
repl_user=repl
repl_password=repl

# 检查频次，每3秒检查一次主节点状态。
ping_interval=3



[server1]
hostname=172.21.0.11 # master1节点的配置，这里对应/etc/hosts中配置的主机名称
candidate_master=1


[server2]
hostname=172.21.0.12 # slave1节点IP地址
candidate_master=1 # 1表示该节点为备选主节点



[server3]
hostname=172.21.0.22  # slave2节点IP地址
no_master=1 # 表示该节点不是备选主节点

root@manager:/etc/mha#

验证MHA配置

在manager节点检查各个节点之间的ssh免密登录是否成功

root@manager:/etc/mha# masterha_check_ssh --conf=/etc/mha/app1.cnf
Mon Mar  1 14:51:47 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Mar  1 14:51:47 2021 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Mon Mar  1 14:51:47 2021 - [info] Reading server configuration from /etc/mha/app1.cnf..
Mon Mar  1 14:51:47 2021 - [info] Starting SSH connection tests..
Mon Mar  1 14:51:48 2021 - [debug]
Mon Mar  1 14:51:47 2021 - [debug]  Connecting via SSH from root@master1(172.21.0.11:22) to root@slave1(172.21.0.12:22)..
Mon Mar  1 14:51:47 2021 - [debug]   ok.
Mon Mar  1 14:51:47 2021 - [debug]  Connecting via SSH from root@master1(172.21.0.11:22) to root@slave2(172.21.0.22:22)..
Mon Mar  1 14:51:48 2021 - [debug]   ok.
Mon Mar  1 14:51:48 2021 - [debug]
Mon Mar  1 14:51:47 2021 - [debug]  Connecting via SSH from root@slave1(172.21.0.12:22) to root@master1(172.21.0.11:22)..
Mon Mar  1 14:51:48 2021 - [debug]   ok.
Mon Mar  1 14:51:48 2021 - [debug]  Connecting via SSH from root@slave1(172.21.0.12:22) to root@slave2(172.21.0.22:22)..
Mon Mar  1 14:51:48 2021 - [debug]   ok.
Mon Mar  1 14:51:49 2021 - [debug]
Mon Mar  1 14:51:48 2021 - [debug]  Connecting via SSH from root@slave2(172.21.0.22:22) to root@master1(172.21.0.11:22)..
Mon Mar  1 14:51:48 2021 - [debug]   ok.
Mon Mar  1 14:51:48 2021 - [debug]  Connecting via SSH from root@slave2(172.21.0.22:22) to root@slave1(172.21.0.12:22)..
Mon Mar  1 14:51:48 2021 - [debug]   ok.
Mon Mar  1 14:51:49 2021 - [info] All SSH connection tests passed successfully.
Use of uninitialized value in exit at /usr/bin/masterha_check_ssh line 44.
root@manager:/etc/mha#

检查主从同步的状态的脚本执行失败，错误信息如下：

root@manager:/etc/mha# masterha_check_repl --conf=/etc/mha/app1.cnf

Mon Mar  1 15:10:33 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Mar  1 15:10:33 2021 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Mon Mar  1 15:10:33 2021 - [info] Reading server configuration from /etc/mha/app1.cnf..
Mon Mar  1 15:10:33 2021 - [info] MHA::MasterMonitor version 0.58.
Mon Mar  1 15:10:34 2021 - [error][/usr/share/perl5/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/share/perl5/MHA/NodeUtil.pm line 201.
Mon Mar  1 15:10:34 2021 - [error][/usr/share/perl5/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Mon Mar  1 15:10:34 2021 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!
root@manager:/etc/mha#

解决方式如下：

# vi /usr/share/perl5/MHA/NodeUtil.pm

sub parse_mysql_major_version($) {
  my $str = shift;
  my $result = sprintf( '%03d%03d', $str =~ m/(\d+)/g );
  return $result;
}

# 改为如下：

# vi /usr/share/perl5/MHA/NodeUtil.pm

sub parse_mysql_major_version($) {
  my $str = shift;
  $str =~ /(\d+)\.(\d+)/;
  my $strmajor = "$1.$2";
  my $result = sprintf( '%03d%03d', $strmajor =~ m/(\d+)/g );
  return $result;
}

启动MHA

进入/etc/mh目录，让日志写在这个目录下面，然后启动MHA，命令如下：

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

启动后可以看到在当前目录下面，有一个名称为nohup.out的文件生成，这里面是记录的MHA服务启动的日志。这样我们的MHA就搭建完成了。

MHA命令介绍

MAH在安装配置好之后，我们需要熟悉以下的命令才能使用MHA。下面介绍一下MHA中涉及到的各种管理命令。

mah-manager命令

在manager节点安装MHA服务后，会有如下的脚本命令可以使用：

• masterha_check_repl：检查当前MySQL集群中的主从复制链路是否正常工作，后面需要跟上--conf=/xx/xx/xx.cnf配置文件的参数。使用示例如下所示：

root@manager:/etc/mha# masterha_check_repl --conf=/etc/mha/app1.cnf
Mon Mar  1 23:30:35 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
# 这里省略输出内容
MySQL Replication Health is OK.
root@manager:/etc/mha#

• masterha_check_ssh：检查MySQL集群中的各个节点ssh免密登录的功能是否可用。使用示例如下所示：

root@manager:/etc/mha# masterha_check_ssh --conf=/etc/mha/app1.cnf
Mon Mar  1 23:32:56 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Mar  1 23:32:56 2021 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Mon Mar  1 23:32:58 2021 - [info] All SSH connection tests passed successfully.
Use of uninitialized value in exit at /usr/bin/masterha_check_ssh line 44.
root@manager:/etc/mha#

• masterha_check_status：检查当前MHA服务的运行状态是running还是stopped。

root@manager:/etc/mha# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:10319) is running(0:PING_OK), master:172.21.0.12
root@manager:/etc/mha#

• masterha_manager：启动MHA服务的命令，后面需要跟上--conf=/xx/xx/xx.cnf配置文件的参数。后台启动示例如下所示：

root@manager:/etc/mha# nohup masterha_manager --conf=/etc/mha/app1.cnf &
[1] 10319
root@manager:/etc/mha# nohup: ignoring input and appending output to 'nohup.out'
root@manager:/etc/mha#

• masterha_stop：停止MHA服务的命令，后面需要跟上--conf=/xx/xx/xx.cnf配置文件的参数。时候示例如下所示：

root@manager:/etc/mha# masterha_stop --conf=/etc/mha/app1.cnf
Stopped app1 successfully.
[1]+  Exit 1                  nohup masterha_manager --conf=/etc/mha/app1.cnf
root@manager:/etc/mha#

• masterha_conf_host： 添加或删除配置的server信息，这个命令用来修改MHA的配置文件信息，修改完成之后，最好把MHA的manager服务重启一下。使用示例如下所示：

# 向配置文件/etc/mha/app1.cnf中添加一个block名称为server4的配置信息。
root@manager:/etc/mha# masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --block=server4 --hostname=172.21.0.23
Wrote server4 entry to app1.cnf .

# 查看添加后的结果如下，发现已经增加了一个server4的block信息
root@manager:/etc/mha# tail -6 /etc/mha/app1.cnf
[server3]
candidate_master=1
hostname=172.21.0.22

[server4]
hostname=172.21.0.23
root@manager:/etc/mha#


# 删除一个节点server4的配置信息，--command=remove也可以，等于delete也可以。
root@manager:/etc/mha# masterha_conf_host --command=delete --conf=/etc/mha/app1.cnf --block=server4 --hostname=172.21.0.23
Deleted server4 entry from /etc/mha/app1.cnf .

# 查看删除后的效果如下，发现配置文件中已经没有server4的block配置信息了
root@manager:/etc/mha# tail -6 /etc/mha/app1.cnf
candidate_master=1
hostname=172.21.0.12

[server3]
candidate_master=1
hostname=172.21.0.22
root@manager:/etc/mha#


# 在新增加的block中，增加更多的配置信息，可以使用--params="key=val,key=val,key=val..."这样的方式来做，如下：
root@manager:/etc/mha# masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --block=server4 --hostname=172.21.0.23 --params="no_master=1;ignore_fail=1"
Wrote server4 entry to /etc/mha/app1.cnf .

# 检查配置后的结果如下，可以发现我们使用参数--params指定的key和value也配置成功了。
root@manager:/etc/mha# tail -6 /etc/mha/app1.cnf
hostname=172.21.0.22

[server4]
hostname=172.21.0.23
ignore_fail=1
no_master=1
root@manager:/etc/mha#

• masterha_master_switch：控制故障转移的脚本，当MHA发现原先的主宕机之后，会使用这个脚本来进行切换。或者我们可以手动的调用这个脚本来实现手动的转移。使用示例如下所示：

# 确定现在的主节点slave1已经死掉，将原先的主master1提升为新的主。
root@manager:/etc/mha# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=dead --dead_master_host=slave1 --new_master_host=master1

# 确定现有的主slave1已经死掉，由MAH自己选择新的主。
root@manager:/etc/mha# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=dead --dead_master_host=slave1

• masterha_master_monitor：检查master节点是否宕机，使用示例如下所示：

root@manager:/etc/mha# masterha_master_monitor --conf=/etc/mha/app1.cnf

• masterha_secondary_check：检查备选主节点的状态，使用示例如下所示：

root@manager:/etc/mha# masterha_secondary_check -s slave1 --user=root --master_host=slave1.mysql --master_ip=172.21.0.12 --master_port=3306
Master is reachable from slave1!
root@manager:/etc/mha#

mha-node命令

在其他MySQL服务器节点安装MHA服务之后，会有如下的脚本命令可以使用：

• save_binary_logs : 保存和复制master的二进制日志。
• apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。
• filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。
• purge_relay_logs : 清除中继日志，这个清除relay log的命令不会阻塞SQL线程，使用示例如下所示：

这里说明一下为什么在node节点上面会有这个purge_relay_logs的命令呢？MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。

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

mah-自定义脚本

除了上面直接提供的命令之外，还可以自定义如下的脚本命令：

• secondary_check_script：通过多条网络路由检测master的可用性；
• master_ip_failover_script：更新application使用的masterip，需要自己根据环境需求适当修改。
• shutdown_script：强制关闭master节点。
• report_script：发送邮件报告。
• init_conf_load_script：加载初始配置参数，如果你的MySQL中的相关密码，不想配置在明文中，可以参考这个脚本来做。
• master_ip_online_change：更新master节点ip地址，需要自己根据环境需求适当修改。

主从切换的验证

现在我们来动态的验证一下，MHA是否可以真正地做到在master1节点宕机之后，会自动的完成主从切换的功能。

监控manager节点的日志

首先，我们观察一下在MHA的监控节点的manager上面的日志输出是什么内容。可以在停止主节点的MySQL服务器之前，使用如下命令动态观察日志的输出内容，然后我们再去停止主节点的MySQL服务。

tail -f /etc/mha/nohup.out

停止master1节点

然后我们在主节点，停止MySQL数据库服务，使用如下两种方式中的任何一种都可以：

# 在master1节点容器的内部执行如下命令：
/etc/init.d/mysql stop

# 或者在docker的宿主机上面执行如下命令，关闭容器
docker stop mysql-ha-mha-master1

验证主从切换结果

此时我们会发现manager上面的日志输出，主从同步的主节点从原先的master1上迁移到了从节点slave1上面。salve2节点也自动的把主从同步的链路从master1改为了slave1上面。下面分别在slave1和slave上面执行如下的命令：

Slave1节点如下，可以看出它没有从节点的状态了，已经不再是从节点了，变成了一个新的主节点。并且有master的状态。

/* slave1上面执行的结果如下 */
mysql> show slave status\G
Empty set (0.00 sec)

mysql> show master status;
+-------------------------+----------+--------------+------------------+-------------------+
| File                    | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------------+----------+--------------+------------------+-------------------+
| slave1-mysql-bin.000001 |     1229 |              |                  |                   |
+-------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

mysql> insert into tab values(3),(4),(5);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from tab;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  5 |
+----+
5 rows in set (0.00 sec)

mysql>

Slave2节点如下，可以看到它可以成功的同步到salve1节点上面插入的数据，主从复制的链路已经切换为salve1作为它的主库，不再是之前的master1作为它的主库了。

/* slave2上面执行的结果如下 */
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.21.0.12
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: slave1-mysql-bin.000001
          Read_Master_Log_Pos: 1229
               Relay_Log_File: mysql-relay.000002
                Relay_Log_Pos: 327
        Relay_Master_Log_File: slave1-mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
        		             ......... /*省略输出*/
             Master_Server_Id: 12
                  Master_UUID: 401afbfb-7a2b-11eb-b8e5-0242ac15000c
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                         ......... /*省略输出*/
           Master_TLS_Version:
1 row in set (0.00 sec)

mysql> select * from tab;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  5 |
+----+
5 rows in set (0.00 sec)

mysql>

当主从节点切换之后，MHA的服务会自动停止。此时我们从manager节点上查看一下MHA的运行状态如下：

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

同时我们在/var/log/mha/app1目录下面会发现如下一个标识文件，这个文件没有任何内容，只是一个标记文件。如果要再次启动MHA服务，则必须删除这个标记文件才可以正常启动MHA。

root@manager:/etc/mha# ls -lstr /var/log/mha/app1/*
0 -rw-r--r-- 1 root root 0 Mar  1 20:29 /var/log/mha/app1/app1.failover.complete
root@manager:/etc/mha#

恢复master1节点

在重新启动MHA之前，我们需要把宕机的master1节点恢复一下，让其作为一个slave节点加入到集群中去。从slave1中开始同步数据，因为此时salve1就是当前集群中的主节点。

但是在宕机的master1加入集群之前，需要把落下的数据追赶上当前的主节点。那么到底从哪里开始同步当前主节点的数据呢？在MHA的日志文件中，记录着需要从哪里开始同步当前主上面的数据。有一个change master的语句在日志文件中，如下所示：

root@manager:/etc/mha# cat nohup.out | grep "CHANGE MASTER"
Mon Mar  1 20:29:36 2021 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='172.21.0.12', MASTER_PORT=3306, MASTER_LOG_FILE='slave1-mysql-bin.000001', MASTER_LOG_POS=1229, MASTER_USER='repl', MASTER_PASSWORD='xxx';
Mon Mar  1 20:29:37 2021 - [info]  Executed CHANGE MASTER.
root@manager:/etc/mha#

我们只要在master1节点上执行上面的CHANGE MASTER语句，然后执行start slave命令就可以开始从上次宕机的时间点开始同步数据。等待追上当前的主节点的数据之后，我们就可以再次启动MHA监控服务了。

再次启动MHA服务

在宕机的节点被恢复并且追上集群中现有的master节点之后，在manager节点，使用如下命令开启MHA服务。

# 先删除上一次主从切换成功的标识文件
rm /var/log/mha/app1/app1.failover.complete

# 后台启动MHA监控服务
nohup masterha_manager --conf=/etc/mha/app1.cnf &

如果没有在/etc/mha/app1.cnf配置文件中定义manager服务的输出日志文件，那么会在当前目录下面的nohup.out文件中输出。有如下的输出日志时候，就表示MHA又一次启动成功了。如果定义了日志文件的目录和名字，可以到对应的目录和日志文件中查看日志。

root@manager:/etc/mha# tail -10 nohup.out
172.21.0.12(172.21.0.12:3306) (current master)
 +--172.21.0.11(172.21.0.11:3306)
 +--172.21.0.22(172.21.0.22:3306)

Mon Mar  1 21:15:56 2021 - [warning] master_ip_failover_script is not defined.
Mon Mar  1 21:15:56 2021 - [warning] shutdown_script is not defined.
Mon Mar  1 21:15:56 2021 - [info] Set master ping interval 1 seconds.
Mon Mar  1 21:15:56 2021 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Mon Mar  1 21:15:56 2021 - [info] Starting ping health check on 172.21.0.12(172.21.0.12:3306)..
Mon Mar  1 21:15:56 2021 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..
root@manager:/etc/mha#

VIP漂移的三种方式

详见主页中的：MySQL高可用架构-MHA(下)