当master_manager监控到主库mysqld服务停止后，首先对主库进行SSH登录检查（save_binary_logs -command=test），然后对mysqld服务进行健康检查（PING(SELECT)每个3秒检查一次，持续3次），最后作出Master is down!的判断，master failover开始
第1步：先根据配置文件检测当前的复制环境中有哪些服务器，MHA也会校验诸如复制异常以及是否存在一些从库有不同的主库，启动failover（排除上次failover失败或者failover时间间隔太短）
第2步：隔离master server，把故障主库的VIP停掉（前提是你需要指定相关的脚本，比如：如果有master_ip_failover_script则会调用脚本停掉VIP、如果有shutdown_script脚本则调用脚本关闭master避免脑裂，在安装包的samples/scriptes目录下）
第3步：选举新主库并尽量补全新主库的数据。
3.1 获取同步位置最靠前的从库：对比所有从库的master_log_file和read_master_log_pos位置找出执行位置最新和最旧的从库对应的故障主库的binlog位置。
3.2保存dead master的binlog：在故障主库上执行save_binary_logs命令获得lastest slave同步位置与master间的binlog差异（使用3.1步骤找到的同步最靠前的从库binlog位置，如果故障主库系统没挂的情况下）并scp到monitor server上。
3.3 确定新的主库：先使用命令apply_diff_relay_logs --command=find把前面3.1步骤中找出的同步位置最靠前和最靠后的对应主库的binlog位置作为参数，在同步位置最靠前的从库上执行这个命令在其中继日志中找出两个binlog位置之间的relay log并生成文件用于恢复其他从库（这里就是检查同步最靠前的从库是否有从最老的位置开始的中继日志，这也是为什么MHA环境中执行过的中继日志不能删除的原因，否则这个对比就比较麻烦）。
接着寻找及决定新的主库，根据配置选择如何提升新主库(检查是否有设置candidate_master=1和no_master=1，如果有设置候选主库，那么候选主库中标，但候选库不一定就是有最新数据的slave，所以需要跟其他从库进行比较，当然如果候选主库恰好是同步位置最靠前的从库，就不需要跟其他从库进行relay log比较了；如果没有设置候选主库，那么同步位置最靠前的从库中标)。monitor server也会将之前复制的差异binlog复制到新主库上。
3.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（如果新主库就是同步位置最靠前的从库，那么只需要执行monitor server发过来的差异日志即可），然后使用这两个差异日志进行恢复数据（apply_diff_relay_logs --command=apply命令）。恢复完成后获取binlog位置并生成change master语句准备用于其他从库change master到新的主库上，并设置read_only=0。然后把VIP绑定到新的主库上。到这步骤新的主库切换完成。
第4步：其他从库恢复：将其他从库数据尽量补全（所有从库并行执行）。
4.1 并行使用apply_diff_relay_logs --command=generate_and_send命令判断各个从库的relay log位置和同步位置最靠前的从库之间的relay log差异，并把差异文件从同步位置最靠前的从库上发送到对应的各个从库上。
4.2 并行使用两个差异日志进行恢复：将monitor server上的binlog差异拷贝到各个从库上，然后各个从库通过master_log_file=relay_master_log_file,read_master_log_pos=exec_master_log_pos先确认自己已经执行完成复制，再应用两个差异日志恢复数据。最后，执行reset slave，并重新CHANG MASTER到新主库上。
第5步：新主库执行reset slave操作清除之前slave信息，到这里故障主库切换到新主库完成。
注意：如果中途有意外发生会终止failover操作，并产生mha_manager.failover.error的文件，下一次必须要删除该文件才能正常failover，New Master延时超过30s或者binglog差100M时不会Auto Failover。
二、在线手动切换过程
第1步：配置检测：根据配置文件检测主从关系以及确定有哪些存活的服务器，然后在master上执行FLUSH NO_WRITE_TO_BINLOG TABLES命令关闭打开的表。再检查从库到主库的复制是否正常。并根据配置决定新的主库。
第2步：执行FLUSH TABLES WITH READ LOCK锁住所有的表阻塞主库的写操作。等待其他从库复制追赶上主库。这里建议部署master_ip_online_change_script 脚本，该脚本会自动阻塞以及kill原master session，置原master为只读，停掉VIP（获取旧主库的binlog位置，使用master_log_wait()函数追赶主库）。同步完成之后，获取新主库的binlog位置，生成change master语句准备用于其他从库切换到新主库。
第3步：所有其他从库并行切换主库到新主库。使用第二步骤获取的旧主库的binlog位置，所有其他从库使用master_log_wait()函数追赶主库。然后使用change master切换到新的主库上。
第4步：旧主库unlock tables,并change master到新的主库上。
第5步：新的主库reset slave，绑定VIP在新的主库上。
注：本文为根据MHA切换输出日志整理，个人理解如有错误，还望指正！