MHA+MySQL实现mysql高可用
当master_manager监控到主库mysqld服务停止后，首先对主库进行SSH登录检查（save_binary_logs --command=test），然后对mysqld服务进行健康检查（PING(SELECT)每隔3秒检查一次，持续3次），参数secondary_check_script可用于double check，最后作出Master is down!的判断，master failover开始 1、先根据配置文件检测当前的复制环境中有哪些服务器，MHA也会校验诸如复制异常以及是否存在一些从库有不同的主库，启动failover（排除上次failover失败或者failover时间间隔太短）2、隔离master server，把故障主库的VIP停掉（前提是你需要指定相关的脚本，比如：如果有master_ip_failover_script则会调用脚本停掉VIP、如果有shutdown_script脚本则调用脚本关闭master避免脑裂，具体在配置文件中app1.cnf）
3、选举新主库并尽量补全新主库的数据
1、获取同步位置最靠前的从库：对比所有从库的master_log_file和read_master_log_pos位置找出执行位置最新和最旧的从库对应的故障主库的binlog位置
2、保存dead master的binlog：在故障主库上执行save_binary_logs命令获得lastest slave同步位置与master间的binlog差异（使用3.1步骤找到的同步最靠前的从库binlog位置，如果故障主库系统没挂的情况下）并scp到mha manager server上
scp from root@192.168.142.48:/data/mha/mha/tmp/saved_master_binlog_from_192.168.142.48_5700_20180525155119.binlog to local:/data/mha/mha/app1/saved_master_binlog_from_192.168.142.48_5700_20180525155119.binlog succeeded.
3、确定和决定新的主库
确定新的主库：先使用命令apply_diff_relay_logs --command=find把前面3.1步骤中找出的同步位置最靠前和最靠后的对应主库的binlog位置作为参数，在同步位置最靠前的从库上执行这个命令在其中继日志中找出两个binlog位置之间的relay log并生成文件用于恢复其他从库（这里就是检查同步最靠前的从库是否有从最老的位置开始的中继日志，这也是为什么MHA环境中执行过的中继日志不能删除的原因，否则这个对比就比较麻烦）
接着寻找及决定新的主库，根据配置选择如何提升新主库(检查是否有设置candidate_master=1和no_master=1，如果有设置候选主库，那么候选主库中标，但候选库不一定就是有最新数据的slave，所以需要跟其他从库进行比较，当然如果候选主库恰好是同步位置最靠前的从库，就不需要跟其他从库进行relay log比较了；如果没有设置候选主库，那么同步位置最靠前的从库中标)。mha manager server也会将之前复制的差异binlog复制到新主库上
4、新的主库应用日志(如果有任何错误从这个阶段会发生，需要手动恢复)
新的主库首先需要对比master_log_file=relay_master_log_file,read_master_log_pos=exec_master_log_pos确认自己已经执行完成复制，如果新的主库不是同步位置最靠前的从库，那么需要使用apply_diff_relay_logs --command=generate_and_send命令比较自己和同步位置最靠前的从库之间的relay log是否存在差异，如果存在则需要生成一个差异relay log（如果新主库就是同步位置最靠前的从库，那么只需要执行mha manager server发过来的差异日志即可），然后使用这两个差异日志进行恢复数据（apply_diff_relay_logs --command=apply命令）。恢复完成后获取binlog位置并生成change master语句准备用于其他从库change master到新的主库上，并设置read_only=0。然后把VIP绑定到新的主库上。到这步骤新的主库切换完成
4、其他从库恢复：将其他从库数据尽量补全（所有从库并行执行）
并行使用apply_diff_relay_logs --command=generate_and_send命令判断各个从库的relay log位置和同步位置最靠前的从库之间的relay log差异，并把差异文件从同步位置最靠前的从库上发送到对应的各个从库上
并行使用两个差异日志进行恢复：mha manager server上的binlog差异拷贝到各个从库上，然后各个从库通过master_log_file=relay_master_log_file,read_master_log_pos=exec_master_log_pos先确认自己已经执行完成复制，再应用两个差异日志恢复数据。最后，执行reset slave，并重新CHANG MASTER到新主库上
5、清理新master的相关信息，到这里故障主库切换到新主库完成
Resetting slave info on the new master..
页:
[1]