本文介绍: 我们并没有在MHA中配置强制主库的参数,因此第一个算法不会生效,根据所有从库的信息来看,和主库的数据是一模一样的,不存在数据差异,因此第二个算法也不会生效,而在MHA的配置文件中,是根据主从从节点的顺序来书写的,mysql-1、mysql-2、mysql-3,根据第三个算法,那么当主库故障后,mysql-2这个节点的从库会提升为主库。mysql-2中的从库已经成为新的主库了,当查看slave的状态时,没有任何输出,就表示它是主库。故障的主库已经成功的修复完成,并且已经成为mysql-2新主库的从库。

1.分析主库故障后哪一个从库会切换为主库

在模拟MHA高可用集群主库故障之前,我们先来分析一下,主库故障后,谁会切换为新主库。

Manager组件选举新主库的过程:

Manager组件选举新主库有三种算法:

  • 当主库故障后,如果配置文件中有声明哪个节点强制为主库,该节点会强制提升为新的主库。
  • 当主库故障后,判断剩余从库谁的数据最新(根据Position或者GTID来判断),谁复制主库的数据最多,最多的节点提升为新主库。
  • 当主库故障后,如果剩余从库的Position或者GTID都一一致,也就意味着剩余从库复制的数据都一样多,那么此时就会根据配置文件中的书写顺序,从上到下,最上面的那个节点会成为新主库。

我们并没有在MHA中配置强制主库的参数,因此第一个算法不会生效,根据所有从库的信息来看,和主库的数据是一模一样的,不存在数据差异,因此第二个算法也不会生效,而在MHA的配置文件中,是根据主从从节点的顺序来书写的,mysql-1、mysql-2、mysql-3,根据第三个算法,那么当主库故障后,mysql-2这个节点的从库会提升为主库。

image-20220709161120631

在模拟故障之前,一定要保证MHA是运行的,否则不会切换主从。

2.模拟主库故障观察剩余从库的状态

2.1.模拟主库故障

1)模拟主库故障

[root@mysql-1 ~]# systemctl stop mysqld

2)观察mysql-2中的从库是否会成为新主库

mysql-2中的从库已经成为新的主库了,当查看slave的状态时,没有任何输出,就表示它是主库。

[root@mysql-2 ~]# mysql -uroot -p123456
mysql> show slave status G;
Empty set (0.00 sec)

ERROR: 
No query specified

image-20220709161813983

3)观察mysql-3从库的状态信息

此时mysql-3上的从库已经开始复制mysql-2这个新主库了,MHA故障切换成功,保障了高可用

image-20220709161853375

故障切换完成后,MHA会自动自杀,一次性高可用故障切换。

image-20220709161948336

故障切换的过程可以在MHA的日志中看到。

image-20220709163248361

2.3.当前主从架构

主库已经故障,mysql-2成为了新主库,mysql-3复制mysql-2的数据。

image-20220709163033574

3.修复故障的主库

3.1.修复主库

当我们得知主库故障,并且顺利进行故障切换,使从库成为主库,重新设置了主从关系,保证业务的高可用之后,我们就需要去修复主库了,MHA已经将mysql-2这个从库提升为新的主库了,我们也不需要去改变现有的主从关系,直接让恢复的主库复制现有的主库即可,避免破坏现有主从关系,导致业务中断。

MHA切换主库,就好比某个皇帝(大明战神 明堡宗)御驾亲征,最后被俘虏了(主库故障),他的弟弟临危受命当了皇帝(mysql-2成为了新主),结果哥哥重新回来后(主库修复),居然夺门,废了弟弟的皇位(想重新成为主),实在不地道了。

1)修复主库

[root@mysql-1 ~]# systemctl start mysqld

2)配置故障的主库复制新主库mysql-2

关于复制参数,我们可以从mha的日志中获取。

[root@mysql-3 ~]# grep 'CHANGE MASTER TO' /data/mha/logs/manager.log
Sat Jul  9 16:15:20 2022 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.20.12', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='replicas', MASTER_PASSWORD='xxx';

配置故障主库复制新主库。

mysql> CHANGE MASTER TO
  MASTER_HOST='192.168.20.12',
  MASTER_USER='replicas',
  MASTER_PASSWORD='123456',
  MASTER_PORT=3306,
  MASTER_AUTO_POSITION=1;
mysql> start slave;

故障的主库已经成功的修复完成,并且已经成为mysql-2新主库的从库。

image-20220709164716067

3.2.当前主从架构

mysql-2是主库,mysql-1是故障主库,恢复后成为了mysql-2的从库。

image-20220709164846865

3.3.恢复MHA

MHA在完成一次故障切换后,会自动杀死自己,因此我们需要去恢复MHA,首先将故障的主库重新添加到配置文件中,因为MHA切换时会将故障的节点从配置文件中删除,然后再启动MHA即可。

1)将故障的主库重新加入到配置文件中

[root@mysql-3 ~]# vim /data/mha/app1.cnf 
[server1]
hostname=192.168.20.11
port=3306

2)启动MHA

[root@mysql-3 ~]# nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /data/mha/logs/manager.log 2>&1 &

3)查看状态

[root@mysql-3 ~]# masterha_check_status --conf=/data/mha/app1.cnf
app1 (pid:11050) is running(0:PING_OK), master:192.168.20.12

原文地址:https://blog.csdn.net/weixin_44953658/article/details/136036257

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如若转载,请注明出处:http://www.7code.cn/show_66579.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注