MHA切换过程（精细）

* Phase 1: Configuration Check Phase..

检查当前存活实例及主从同步状态，是否可以进行切换

* Phase 1: Configuration Check Phase completed.

 

* Phase 2: Dead Master Shutdown Phase..

去掉VIP

如果配置了shutdown_script,在VIP去掉后执行shutdown_script

* Phase 2: Dead Master Shutdown Phase completed.

 

* Phase 3: Master Recovery Phase..

* Phase 3.1: Getting Latest Slaves Phase..

找出latest slave,根据Read_Master_Log_Pos最多,查看当前位置点

 

* Phase 3.2: Saving Dead Master''s Binlog Phase..

根据latest上位置点，从dead master 提取差异binlog

将提取出来的差异日志scp到监控节点

 

* Phase 3.3: Determining New Master Phase.. #检测新主

检查latest slave的relay log，是否可以恢复其他slave

根据config里面配置，选择出new master

 

* Phase 3.3: New Master Diff Log Generation Phase..

从latest slave上获取差异relay log(因实例日志里面new master就是latest slave,所以不需要此步操作)

监控节点将3.2步接收到的差异binlog，发送到new master上面

 

* Phase 3.4: Master Log Apply Phase..

应用diff realy log,此时new master与latest slave数据一致

应用监控节点发过来的差异日志，此时new master数据已经与dead master一致

查看new master binlog位置，同时生成CHANGE MASTER语句，所有slave同步从此位置开始

添加VIP

* Phase 3: Master Recovery Phase completed.

 

* Phase 4: Slaves Recovery Phase..

* Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..

                       slave从latest slave上获取差异relay log，生成文件并scp到slave本地

 

* Phase 4.2: Starting Parallel Slave Log Apply Phase..

监控节点将3.2步接收到的差异binlog，发送到slave上面

将在latest slave上面获取到的差异relay log合成到total_binlog_for_xxx

检查差异binlog的120位之前是否有效，通常120之前为binlog头信息和rotate信息，无实际意义，只合成有效日志

应用上面合成的日志

reset slave &&change master

检查所有slave是否recovery成功

 

* Phase 5: New master cleanup phase..

在new master上面,清空复制信息