前提条件

1.复制

2.ssh

3.彼此能够通过客户端连接数据库

4.所有节点有相同的复制用户和密码

5.只有一个写节点，所有其他都配置成read_only

6.5.0或更新版本

7.candidate应该开启binlog

8.binlog filter在所有服务器上都一样

9.禁用relay-log purge，换成cron来处理，或者使用purge_relay_logs脚本

mha node包中包括save_binary_logs, filter_mysqlbinlog, purge_relay_logs, apply_diff_relay_logs

manager用select命令监控master的状态，

1.--remove_dead_master_conf参数的意思是如果master挂掉的话，failover后manager必须将master的配置从配置文件中删除掉，否则，重启manager的时候就会报“there is a dead slave” error，

2.配置文件中所有的列出来的server都必须存在于复制环境中，而且状态都是健康的，即服务存在，否则manager将会罢工

 

自动手动failover

一切都运行正常，那如果这时master挂掉会发生什么呢？

一、自动failover

1.尝试用ssh连接主库读取binlog保存到本地，MHA能应用缺失的binlog events到其余的slave上，更新failover前的状态到最新。Nice！

***********************************************************************************************************************

* Phase 1: Configuration Check Phase..

* Phase 2: Dead Master Shutdown Phase..

* Phase 3: Master Recovery Phase..

* Phase 3.1: Getting Latest Slaves Phase..

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

* Phase 3.3: Determining New Master Phase..

[info] Finding the latest slave that has all relay logs for recovering other slaves..

[info] All slaves received relay logs to the same position. No need to resync each other.

[info] Starting master failover..

[info]

From:

mysql-server1(192.168.1.116:3306) (current master)

+--mysql-server2(192.168.1.117:3306)

+--mysql-server3(192.168.1.118:3306)

To:

mysql-server2(192.168.1.117:3306) (new master)

+--mysql-server3(192.168.1.118:3306)

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

* Phase 3.4: Master Log Apply Phase..

* Phase 4: Slaves Recovery Phase..

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

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

* Phase 5: New master cleanup phase..

***********************************************************************************************************************

2.mha尝试获取master所有的binlog以及slave的relay log(牛逼)，以防数据丢失，同时也是为了能将落后的slave提升为master。

3.failover后，manager服务就自动停止了，这时候我们会发现配置文件中old master的配置项已被删除，现在我们需要手动恢复复制环境，并添加配置到配置文件，然后启动manager

二、手动failover

一般在我们做维护的时候可能需要这么做，比如数据库的滚动升级

1.停止masterha_manager

2.执行masterha_master_switch --master_state=alive --conf=/etc/app1.cnf，这行的意思是说，我想切换master，但实际上master没有挂，所以mha不会认为他挂了，配置文件也不会删除相关配置项

You can also employ some extra parameters that are really useful in some cases

1.--orig_master_is_new_slave，额外添加改参数的话，原主库会变成新主的从库

2.--running_updates_limit，如果当前主的写超过他的参数设置，或者有从库落后主库太多的话，主库切换会终止，默认延迟是1秒，这些限定都是为了安全考虑。

3.--interactive=0，如果想要跳过所有的验证以及 masterha_master_switch的一些交互式的问答的话可以设置增加该参数

如果用GTID并且想要failover的时候避免errant transactions的问题，看这里的

自定义脚本

Binary log servers：如果用GTID，MHA能连接到binlog server，如果binlog server的binlog位点先于其他server的话，mha可以应用这些binlog，。

Custom scripts：如果有故障发生，MHA能够漂移vip，shutdown server，还可以发生邮件，这些工作的话都需要你自定义脚本来完成，MHA本身带有一些脚本样例，但是你自己得根据实际生产环境来做调整，这些脚本包括master_ip_failover_script, shutdown_script, report_script，见名知意