标签：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
标签：mha
原文地址：http://binbinwudi8688.blog.51cto.com/3023365/1878224
