文章目录
- 1.分析主库故障后哪一个从库会切换为主库
- 2.模拟主库故障观察剩余从库的状态
- 2.1.模拟主库故障
- 2.3.当前主从架构
- 3.修复故障的主库
- 3.1.修复主库
- 3.2.当前主从架构
- 3.3.恢复MHA
1.分析主库故障后哪一个从库会切换为主库
在模拟MHA高可用集群主库故障之前，我们先来分析一下，主库故障后，谁会切换为新主库。
Manager组件选举新主库的过程：
Manager组件选举新主库有三种算法：
- 当主库故障后，如果配置文件中有声明哪个节点强制为主库，该节点会强制提升为新的主库。
- 当主库故障后，判断剩余从库谁的数据最新（根据Position或者GTID来判断），谁复制主库的数据最多，最多的节点提升为新主库。
- 当主库故障后，如果剩余从库的Position或者GTID都一一致，也就意味着剩余从库复制的数据都一样多，那么此时就会根据配置文件中的书写顺序，从上到下，最上面的那个节点会成为新主库。
我们并没有在MHA中配置强制主库的参数，因此第一个算法不会生效，根据所有从库的信息来看，和主库的数据是一模一样的，不存在数据差异，因此第二个算法也不会生效，而在MHA的配置文件中，是根据主从从节点的顺序来书写的，mysql-1、mysql-2、mysql-3，根据第三个算法，那么当主库故障后，mysql-2这个节点的从库会提升为主库。
在模拟故障之前，一定要保证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
3）观察mysql-3从库的状态信息
此时mysql-3上的从库已经开始复制mysql-2这个新主库了，MHA故障切换成功，保障了高可用
故障切换完成后，MHA会自动自杀，一次性高可用故障切换。
故障切换的过程可以在MHA的日志中看到。
2.3.当前主从架构
主库已经故障，mysql-2成为了新主库，mysql-3复制mysql-2的数据。
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新主库的从库。
3.2.当前主从架构
mysql-2是主库，mysql-1是故障主库，恢复后成为了mysql-2的从库。
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
