编程开源技术交流,分享技术与知识

网站首页 > 开源技术 正文

MySQL高可用架构-MHA(上)(mysql8高可用)

wxchong 2024-10-06 04:34:45 开源技术 15 ℃ 0 评论

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

  • 前言
  • 创建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(下)

Tags:

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表