首页 > 代码库 > 第4天 二篇、【MHA】故障切换

第4天 二篇、【MHA】故障切换

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

第4天 二篇、【MHA】故障切换