MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中， MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中
(通过将从库提升为主库),大概0.5-2秒内即可完成
自动故障检测和自动故障转移
MHA能够在一个已经存在的复制环境中监控MySQL，当检测到Master故障后能够实现自动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。一个slave节点能否成为候选的主节点可通过在配置文件中配置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节点都有希望成为主节点。在通常的replication环境中由于复制中断而极容易产生的数据一致性问题，在MHA中将不会发生。
注：在MHA的高可用环境的，主库宕机了，MHA服务将停止，如何恢复MHA服务了，需要把宕机的主库加入到高可用环境（也就是把宕机的主库变成从库）在重新启动MHA
交互式（手动）故障转移
MHA可以手动地实现故障转移，而不必去理会master的状态，即不监控master状态，确认故障发生后可通过MHA手动切换
在线切换Master到不同的主机
MHA能够在0.5-2秒内实现切换，0.5-2秒的写阻塞通常是可接受的，所以你甚至能在非维护期间就在线切换master。诸如升级到高版本，升级到更快的服务器之类的工作，将会变得更容易。
自动故障转移快
主库崩溃不存在数据一致性问题
配置不需要对当前mysql环境做重大修改
不需要添加额外的服务器(仅一台manager就可管理上百个replication）
性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
只要replication支持的存储引擎，MHA都支持，不会局限于innodb
MHA组成
MHA由Manager节点和Node节点组成。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。 MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
MHA工作原理
从宕机崩溃的master保存二进制日志事件（binlog events）;
识别含有最新更新的slave；
应用差异的中继日志（relay log）到其他的slave；
应用从master保存的二进制日志事件（binlog events）；
提升一个slave为新的master；
使其他的slave连接新的master进行复制；
MHA安装准备四个节点，其中一个是管理节点，三个是一主两从的环境
MHA项目地址
https://code.google.com/p/mysql-master-ha/
主从环境我这已近搭建好
环境如下：
mycat01 10.0.0.200
master01 10.0.0.201
master02 10.0.0.204
slave02 10.0.0.203
注：master01 是主库 master02是从库 ，slave02 是从库，一主两从
mha 管理节点需要mysql命令环境
在所有节点上安装node节点
yum install –y perl-DBD-MySQL
rpm -ivh mha4mysql-node-0.54-0.noarch.rpm
在管理节点上安装manager节点
yum install -y perl-Config-Tiny
yum install -y perl-Log-Dispatch
yum install -y perl-Parallel-ForkManager
rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm