一、MHA工作原理：
1、主库挂了，但是主库的binlog都被全部从库接收
此时会选中应用binlog最全的一台从库作为新的主库，其他从主只需要重新指定一下主库即可(因为此时,所有从库都是一致的，所以只需要重新指定一下从库即可)。
2、主库挂了，所有的binlog都已经被从库接收了，但是，主库上有几条记录还没有sync到binlog中，所以从库也没有接收到这个event，如果此时做切换，会丢失这个event。
此时，如果主库还可以通过ssh访问到，binlog文件可以查看，那么先copy该event到所有的从库上，最后再切换主库。
3、如果使用半同步复制，可以极大的减少此类风险。
主库挂了，从库上有部分从库没有接收到所有的events
选择出最新的slave，从中拷贝其他从所缺少的events
问题1、
如何确定哪些event没有成功接收？如何让所有从库保持一致？
导致复制问题的原因是因为MySQL采用异步复制，并不保证所有事件被从库接收
对于此类问题的解决方案:
Heartbeat + DRBD
代价：额外的被动master，并且不处理任何流量。
性能：为了保证事件被及时写入，innodb_flush_log_at_trx_commit=1,sync_binlog=1. 这样就会导致性能急速下降
MySQL Cluster
真正的高可用，但是只支持InnoDB
Semi_synchronous Replication (5.5+)
半同步复制极大减少了"binlog事件只存在于master上"的风险。
保证至少有一台从库接收到了提交的binlog事件。其他的从可能没有接收，但是不影响提交了
Global Transaction ID
由谷歌开发的插件。
二、MHA的实施步骤
1、从down的主上面获取到binlog事件
2、确定最新(最全)的从库
3、分别应用不同的relay log事件到其他从库
4、应用从主库上获取的binlog事件(发生故障时的事件)
5、提升一个从库为新的主库(此时从库已经一致)
6、将其他从库的主库重新指定
同时，自动检测主库故障。
三、如何确定最近从库以及丢失的events
1、Master_Log_File,Read_Master_Log_Pos 可以确定(从库的IO线程)读取主库的binlog的最新进度。
2、Relay_Log_File,Relay_Log_Pos 确定SQL线程执行本地Relay_Log的最新进度。
3、由于Relay_Log的进度和binlog是不一样的。所以如果只看Relay_Log的信息无法确定执行事件的实际位置
Relay_Master_Log_File,Exec_Master_Log_Pos 本地SQL线程实际上执行binlog位置(用于计算seconds_behind_master)
4、各个从库之间，比较Master_Log_File,Read_Master_Log_Pos可以确定哪台从库接收到的日志是最完整的。
5、当找出最新最全的从库之后，应用diff到其他从库
仅仅比较上面2个参数是不够确定具体缺失的events
在relay log中日志开头会指定是读哪个binlog，文尾的end_log_pos表示最后读到binlog的位置。
通过对比不同从库上，最新的relay_log中的binlog file和end_log_pos位置来对比还有哪些events缺失(每个at xxx就是一个event)。
############################################################
如果是一个很大的事务，产生了很多日志信息(事务只会保存在一个binlog文件中,但是会出现在2个relay_log中。)
面对这种情形,如果只接受到了部分的events信息。从库是不会重做这些relay_log。
此时的Master_Log_File,Read_Master_Log_Pos 会指向读取到的binlog的最新位置(这是IO线程负责的)，
而Relay_Master_Log_File,Exec_Master_Log_Pos只会指向最后执行的commit事务。
这样就保证了不会使数据库进入不一致状态。那么在接受到其他从库最新日志的时候，也是完整的执行一次该事务(即使自己的Relay log已经有部分记录了)
三、MHA需要考虑的注意事项：
1、如果使用mysqlbinlog打开binlog和relaylog，会自动在文本里面添加rollback关键字所以要在日志中清理掉由mysqlbinlog添加的rollback。
ROLLBACK /* added by mysqlbinlog */
2、由于mha默认关闭relay_log_purge。所以要手动定期清理。
为了保证在发生故障时，能有足够多的relay log用户恢复，所以不应该自动清理。
关闭这个参数之后，SQL线程不会定期清理Relay_log，所以很快会填满磁盘空间。
Relay_log没有像binlog一样有自动过期参数expire_logs_days
定期清理的方式：
set global relay_log_purge=1;
flush logs;/* SQL线程会自动清理多余的Relay_Log_File */
set global relay_log_purge=0;
如果有较大的日志，让SQL线程自动删，会导致SQL线程锁住，从库落后主库。
ln relay-log.* /tmp/archive_dir/
mysql -e"set global relay_log_purge=1;flush logs;set global relay_log_purge=0;"
rm -rf /tmp/archive_dir/* */
这样就不会占用宝贵的SQL线程了。
即便如此也不要在所有的从库上同一时间执行一个计划任务(清除Relay_Log),否则会导致没有Relay_Log用户恢复的情形出现。
3、要确定SQL线程是否执行完所有的events
1）、等待事物执行
2）、select MASTER_POS_WAIT(master_log_file,read_master_log_pos);
如果所有从库已经与主库一致了，上面的命令失效
如果只有部分事物日志传送到从库，SQL线程也不会同步到Read_Master_Log_Pos。
3）、show processlist查看输出。提示:"Has read all relay log;waiting for the slave I/O thread to update it"
4、要处理恶意查询
恶意查询：insert into t1 values(0,0,"ROLLBACK");
5、有多个从库时，并行恢复。
6、采用ROW FORMAT
对于采用row格式记录的日志、
可能出现多个"#at"条目+相同的"end_log_pos"条目。
Table_map+Write_rows+STMT_END
四、故障自动转移的内容：
1、检测master failure
2、Node Fencing(通过干掉故障master 避免脑裂)
3、更新写入IP(VIP)
条件：
通过脚本完成自动转移，同时再故障发生时要自动调用脚本.
1、确保文件和对应的目录存在，SSH互信成功----避免因为低级错误导致转移失败
2、如果有从库服务器挂掉，或者SQL线程挂掉，或者在8个小时内发生过转移了----都不再执行故障转移
如果发生故障：
发送邮件报警
停掉新主库上的备份任务
更新内部工具的管理地址(从旧库指向新库)..
五、MHA工具介绍
1、在manager上
master_monitor：检测master状态
master_switch：执行故障转移(手动执行，如果自动则要使用masterha_manager)
masterha_manager：启动mha，执行mha的管理操作
2、在node上
save_binary_logs：复制主库二进制日志
apply_diff_relay_logs:从最全的slave上生成diff Relay log,应用所有从主库copy来的的binlog中的events
filter_mysqlbinlog:清理掉有mysqlbinlog工具带来的ROLLBACK events
purge_relay_logs:在不停止SQL线程的前提下删除Relay_log
六、MHA处理案例：
master上内核崩溃
10内检查master状态。
确定master不可用之后power off
选择新的master,recovery
并行恢复其他从库
七、MHA的限制：
不支持多级复制 M->M->S
不支持日志为statment级别(SBR)的load data infile
不支持MySQL5.0以前的版本