MHA介绍和基础、原理、架构、工具介绍
一.MHA简介
软件简介
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在10~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中 (通过将从库提升为主库)，大概0.5-2秒内即可完成。
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
MHA在生产环境的作用
一主多从的环境下，MySQL的主从复制是异步或是半同步。
Master发生故障的时候，有可能一部分（或者全部）的Slave未能获取到最新的binlog，造成Slave之间的binlog转发发生偏差。
如下图所示，Master宕机之后，id=102的binlog未能被发送到任何一个Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id-101的binlog
如果想要正确恢复：
- Master必须发出的ID=102的binlog
- 还要消除各个Slave之间的差异性
MHA可以全自动的处理以上这些
最佳方案
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。
MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。
MHA优点总结
1）Masterfailover and slave promotion can be done very quickly
自动故障转移快
2）Mastercrash does not result in data inconsistency
主库崩溃不存在数据一致性问题
3）Noneed to modify current MySQL settings (MHA works with regular MySQL)
不需要对当前mysql环境做重大修改
4）Noneed to increase lots of servers
不需要添加额外的服务器(仅一台manager就可管理上百个replication)
5）Noperformance penalty
性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
6）Works with any storage engine
只要replication支持的存储引擎，MHA都支持，不会局限于innodb
二.工作流程
1)把宕机的master二进制日志保存下来。
2)找到binlog位置点最新的slave。
3)在binlog位置点最新的slave上用relay log（差异日志）修复其它slave。
4)将宕机的master上保存下来的二进制日志恢复到含有最新位置点的slave上。
5)将含有最新位置点binlog所在的slave提升为master。
6)将其它slave重新指向新提升的master，并开启主从复制。
监控所有node节点MHA功能说明：
2、自动故障切换(failover)
前提是必须有三个节点存在，并且有两个从库
(1)选主前提，按照配置文件的顺序进行，但是如果此节点后主库100M以上relay-log 就不会选
(2)如果你设置了权重，总会切换带此节点；一般在多地多中心的情况下，一般会把权重设置在本地节点。
(3)选择s1为新主
(4)保存主库binlog日志
3、重新构建主从
(1)将有问题的节点剔除MHA
进行第一阶段数据补偿，S2缺失部分补全90
(2)s1切换角色为新主，将s2指向新主S1
s2 change master to s1
(3) 第二阶段数据补偿
将保存过来的新主和原有主缺失部分的binlog，应用到新主。
(4)虚拟IP漂移到新主，对应用透明无感知
(5)通知管理员故障切换
三.MHA架构图
1.manager可以单独装在任意一台机器上；
2.一个manager可以管理多套mysql集群；
3.建议不要将manager装在主库上（防止主库断电，断网）；
4.所有数据库必须安装node包；
5.manager的依赖有node
四.MHA工具介绍
MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下：
masterha_check_ssh #检查MHA的
ssh-key masterha_check_repl #检查主从复制情况
masterha_manger #启动MHA
masterha_check_status #检测MHA的运行状态
masterha_master_monitor #检测master是否宕机
masterha_master_switch #手动故障转移
masterha_conf_host #手动添加server信息
masterha_secondary_check #建立TCP连接从远程服务器
masterha_stop #停止MHA
Node工具包主要包括以下几个工具：
save_binary_logs #保存宕机的master的binlog
apply_diff_relay_logs #识别relay log的差异对比
filter_mysqlbinlog #防止回滚事件，截取日志
purge_relay_logs #清除中继日志relay_logs
