第97讲：MHA高可用集群模拟主库故障以及修复过程

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

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

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

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

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

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

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

ERROR: 
No query specified

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

[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;

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

[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 &

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

显示所有内容

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

mysql 主库从库

文章目录

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

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

2.1.模拟主库故障

2.3.当前主从架构

3.修复故障的主库

3.1.修复主库

3.2.当前主从架构

3.3.恢复MHA

发表回复取消回复