整个迁移过程如下：

(1)检查配置文件阶段，检查配置文件中master存活

(2)宕机master保证应用不会连接，会使用shutdown_script配置的脚本；如果master_ip_failover_script设置的话，将会进行VIP漂移切换

(3)master恢复阶段，其中包括：

获取最新的slave的二进制日志

从master上保存二进制日志并和最新的slave上的rilay log对比差异，将差异保存到slave的remote_workdir=/tmp下，然后再将其保存到mha manager上的/var/log/masterha/app1下

选出新的master，如果设置了candidate_master，则优先选为新masterha_conf_host来添加。

对比新master的relay log，生成差异并将mha manager上的日志复制到remote_workdir=/tmp下

将差异应用在新master上

(4)slaves恢复阶段，其中包括：

并行操作，对比relay log

并行操作，将mha managermha manager上的日志复制到remote_workdir=/tmp下，将差异日志应用到slave

(5)将slave提升为新的master，并将老master从配置文件中删除。

大体过程如下，总结的比较吃力，请详见manager.log。

注：1.成功完成一次故障转移后mha manager的监控会停止，若新master出现宕机时failover则不会发生，因此我们需要使用daemontools将将他作为daemon运行

2.当failover完成后，会将老的master从配置文件删除，若我们在修复好老的master后，希望将其作为slave继续使用，我们需要使用masterha_conf_host来添加，如：

?

#添加
masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --block=server100  --hostname=test4 --params="no_master=1;ignore_fail=1"
则会在配置文件中生成：
[server100]
hostname=test4
no_master=1
ignore_fail=1
#删除
masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --block=server100

好了，mha就先写到这里，内容有点多，有可能有错误的地方请指正，另外细节性的东西有很多，稍微不注意就会掉坑里，可能说的不完全，大家可以到官网仔细看看吧。