MHA运维
前提条件
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，见名知意
