第4天 二篇MHA故障切换

Posted 2020-08-21

MHA故障切换：

一、Master自动监控和故障转移

在默认8小时内连续出现故障，则不会切换，可以通过设置--last_failover_minute=(minutes)来缩短时间，但是如果设置了--ignore_last_failover参数，那么该步骤省略。

        与《MHA高可用架构介绍》中恢复过程一样，这里会添加详细操作：

       1） MHA启动之后：

            自动检测主库的binlog文件是否存在（通过Executing SSH check script: save_binary_logs）

            自动检测网络连接（通过Executing secondary network check script: /usr/local/bin/masterha_secondary_check_3307） ---- 我自己的环境截取

       2） MHA宕机之后：

            第一步：配置检查。存活从库(192.168.143.242:3307) 

            第二步：通过SSH关闭死去的从库（我这里没有配置shutdown script,所以无法将主机关闭）******************

            第三步：master恢复阶段

   * 首先检查最新的slave和最老的slave所接收的master上的binlog都是否为mysql-bin.000006:2462
   * 然后保存死去master 的binlog日志(192.168.143.241:3307): save_binary_logs --command=save --start_file=mysql-bin.000006  --start_pos=2462 --binlog_dir=/data/mysql/mysql_3307/binlog --output_file=/var/log/masterha/app2/saved_master_binlog_from_VCrawlerDB-M_3307_20161129170047.binlog --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.56  scp保存到本地（死去的master）
   * 再提升一个新的master，检查MHA的app2.cnf配置文件是否设置了candidate_master=1参数，如果设置了，提升为新的master；未设置，按IP顺序提升
   * 识别死去的master与新master数据差异，如果slave的数据比死去的master要老，那么把这个文件scp到slave上，通过Executing command: apply_diff_relay_logs 识别差异日志并补充数据
   * 生成 Statement should be: CHANGE MASTER TO MASTER_HOST=‘VCDB-S or 192.168.143.242‘, 生成新Master的change
   * 将虚拟IP漂移到新master中Executing master IP activate script: /usr/local/bin/master_ip_failover_app2 --command=start，并关闭只读参数set global read_only=0
    * 恢复最老的slave数据，如果最老的slave的sql_thread还未执行完，那么要先等执行完成，然后检查最老slave执行完成的relay log和position，与最新的master进行对比。
   * 当最老的slave把最新master上的relay log补齐之后，MHA将死去master缺失的那部分binlog发送给最老的slave，通过apply_diff_relay_logs命令将数据补齐，之后再使用上面所生成的change master to与最新master进行同步复制关系。

                           

二、Master手工故障转移

           

    通过masterha_master_switch --conf=/etc/mha/app2.cnf --master_state=dead --ignore_last_failover --dead_master_host=Master --dead_master_ip=192.168.143.241 --dead_master_port=3307实现

三、在线平滑切换

    masterha_master_switch --conf=/etc/app1.cnf --master_state=alive --orig_master_is_new_slave --running_updates_limit=1

切换包括以下方面：

        第一步：

        1）配置检查：当前存活的master与slave

        2）输入yes,在原master上执行flush no_write_to_binlog tables，强制将打开的表关闭，业务繁忙时，会耗费很长时间。

        3）输入yes，确认把master切换到slave上

        4）拒绝更新，防止原主库被写入数据

            * 将原Master上的虚拟IP清除

            * 设置原master为只读模式，set global read_only=1

            * kill掉所有应用链接的线程

            * 执行flush tables with read lock全局锁

            * 在原master上执行select master_post_wait(mysqld-bin.000023:234324),等待slave把relay log执行完，并生成新的change master to 语句。

        第二步：

1) 将VIP切换到slave1上

2) 设置slave1(新提升的master)为读写模式set global read_only=0

3) 在slave2上执行change master to slave1

4) 在原master上解除锁表unlock tables

5) 在原master上执行change master slave1

6) 在slave1（新提升的master）上执行reset slave all，清空之前的同步复制信息

7) 整个切换流程结束

上面的过程，是我根据自己的线上测试日志与书本结合写的。大家实验过程中，慢慢的去看测试日志，就能了解到整个过程的。

本文出自 “崛起” 博客，请务必保留此出处http://binbinwudi8688.blog.51cto.com/3023365/1878224