Overview
MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内;在复制框架中，MHA能够很好地解决复制过程中的数据一致性问题，由于不需要在现有的replication中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所以能大大地节约服务器的数量;另外，安装简单，无性能损耗，以及不需要修改现有的复制部署也是它的优势之处。MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。
MHA提供了上述功能，使得其在适用于对高可用性，数据完整性要求高的场合，还有要求几乎non-stop的主库维护。
◎自动故障检测和自动故障转移
MHA能够在一个已经存在的复制环境中监控MySQL，当检测到Master故障后能够实现自动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。通常情况下MHA能够达到如下指标：9-12秒检测到主库故障，7-10秒关闭master所在的mysqld服务以防止故障扩散，并在几秒内实现各个slave上的relay log重放到新的master。总共的down time通常控制在10-30秒内。一个slave节点能否成为候选的主节点可通过在配置文件中配置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节点都有希望成为主节点。在通常的replication环境中由于复制中断而极容易产生的数据一致性问题，在MHA中将不会发生。◎交互式（手动）故障转移
MHA可以被定义成手动地实现故障转移，而不必去理会master的状态，即不监控master状态，确认故障发生后可通过MHA手动切换。◎非交互式的故障转移
即不监控Master状态，但是发生故障后可通过MHA实现自动转移。◎在线切换Master到不同的主机
通常当RAID控制器或者RAM损坏，或者需要将现有的master服务器进行升级的时候，我们就需要切换当前的master到其他的主机中。这并不是主库崩溃，但是却需要我们手动切换。这通常是越快越好，因为这段时间内主库是写禁止的。所以，你还需要阻塞或删除正在进行的会话，因为不禁止写就会导致数据一致性问题。举个例子，updating master1, updating master 2,committing master1, getting error on committing master 2就会导致数据一致性问题。所以说，快速的切换和优美平滑的阻塞写都是需要的。MHA能够在0.5-2秒内实现切换，0.5-2秒的写阻塞通常是可接受的，所以你甚至能在非维护期间就在线切换master。诸如升级到高版本，升级到更快的服务器之类的工作，将会变得更容易。
Architecture of MHA
当主库发生崩溃，MHA通过以下方式修复
MHA Components
MHA由Manager节点和Node节点组成。
Manaer模块：可以管理多套Master-Slave Replication
Masterha_manager：提供实现自动故障检测和故障转移的命令其他帮助脚本：提供手工故障转移，在线master切换，con 检查等功能
Node模块：部署在所有的MySQL Server上
Save_binary_logs:如有必要，复制master的二进制日志Apply_diff_relay_logs:从数据最新的slave上产生不同的relay log，并且将其应用到不同的binlog events中
Purge_relay_log：清除relay log
MHA manager节点上运行着这些程序：监控mysql状态，master故障转移等。
MHA node节点上有实现自动故障转移的helper脚本，比如分析mysql binary/relay log，认出哪一个relay log应该应用到其他的slave，并识别出这个relay log的位置，并将events应用到目标slave上等。Node节点应该运行在每一个mysql server上。
如果MHA Manager挂掉了，MHA会尝试通过SSH连接到node节点并执行node节点的命令
Advantages of 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 (5.0 orlater))
不需要对当前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
Typical Use cases
怎么部署Manager节点
◎设置一个专门的Manager Server和多个Replication环境
由于MHA manager仅仅使用了非常少的cpu和内存资源，所以你可以让一个manager管理很多个replication，甚至超过100个replication◎Manager节点和一个salve节点复用
假如你只有一个replication环境，而且你可能不喜欢为配置一个专门的manager而花费了更多的硬件开销，那么你可以让manager和一个slave节点复用。值得注意的是，如果这么配置了，尽管manager和slave在同一台机子上了，但是manger依旧通过SSH连接到slave，所以你依旧需要配置SSH无密码登陆。复制配置（这一部分简略翻译）
Singlemaster, multiple slaves
一主多从，这是最普遍的情况。
Singlemaster, multiple slaves (one on remote datacenter)
一主多从，将其中一个从配置成远程数据中心，其永远不会成为master
Singlemaster, multiple slaves, one candidate master
一主多从，并只配置一个候选主节点
Multiplemasters, multiple slaves
Threetier replication
