常用MySQL不同高可用方案的对比（下图来自官方手册）


能实现自动数据库故障转移的方案只有MySQL Cluster和DRBD+Heartbeat，这也是两种不依赖Replication的HA方案。

但是，MySQL Cluster（NDB）配置维护复杂，不像Replication一样稳定易用，大部分公司可能不会考虑这一方案；而DRBD的额外性能消耗又比较大，约为20%—30%，在可用性上大打折扣。

因此，对于我们来说，在Replication的基础上设计HA方案是最好的选择。

MySQL支持单向、异步的复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。MySQL5.5引入了一种半同步复制功能，该功能可以确保主服务器和访问链中至少一台从服务器之间的数据一致性和冗余。

由于MySQL复制的异步性（最多半同步），所以，简单的MySQLReplication + Heartbeat的HA架构只能完成IP的故障转移，而不能完成数据库的故障转移，即不能保证数据一致性。

怎样在故障转移时保证复制架构中的数据一致性
1 找出同步最成功的一台从服务器（也就是与主服务器数据最接近的那台从服务器）。
2 如果主机还能够访问，从主服务器上找回最新从机与主机间的数据差异。
3 在每一台从服务器上操作，确定他们缺少哪些events，并分别进行补充。
4 将最新的一台从服务器提升为主服务器后，将其它从服务器重新指向新的主服务器。

以上这些MHA已经可以实现了。
MHA（Master HA）是一款开源的MySQL的高可用工具，能在MySQL主从复制的基础上，实现自动化主服务器故障转移。
不过，虽然MHA试图从宕机的主服务器上保存二进制日志，但并不是总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失最新数据。

使用半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此他们彼此保持一致性。

Auto Failover Cluster实现方案
在Replication的基础上，MHA能够帮助我们实现数据库的故障转移，但是对于一套完善的自动故障转移群集来说，这是远远不够的，我们还需要实现以下需求：
1 当群集内的数据库进行故障转移时，对外提供服务的虚拟IP也进行转移；
2 MHA管理进程需要以后台守护进程的方式运行，并有监控机制保证MHA管理进程的正常运行；
3 有监控机制保证当主机出现故障时，MHA能确定进行成功的Failover；
4 当故障主机恢复后，能重新回到群集中，并成为新的Slave，自动实现重新同步；
5 由于主机和从机上备份策略不同，进行故障转移后，自动调整cron中的调度（例如全备份）。

完整的自动故障转移群集包括：
MySQL Replication 实现：数据同步
MHA(MasterHA) 实现：心跳检测和数据库故障转移
Heartbeat的IP管理模块 实现：IP故障转移
Perl实现的自定义管理和监控脚本 实现：自动重新同步和保障Cluster正常工作
架构图

完成后的自动故障转移集群能按照计划实现我们的需求，在内部测试环境的测试结果如下（数据库服务器为4核+8G内存的vmware虚拟机，安装centos5.8+MySQL5.5.21）：

测试场景
failover耗时
保证数据完整性
自动重新同步数据
主机MySQL服务停止响应
< 15seconds
是
是
主机CentOS停止响应
< 40seconds
是
是
复制延迟（未传送日志500M）＋MySQL服务停止响应
4.2～4.5m
是
是
复制延迟（未执行日志500M）＋MySQL服务停止响应
1.9～2.1m
是
是
复制延迟（未传送日志500M）＋主机CentOS停止响应
< 40seconds
数据丢失
由于数据丢失,无法自动重新同步
复制延迟（未执行日志500M）＋主机CentOS停止响应）
2.5～2.7m
是
是

目前自动故障转移群集已在我们的生产环境应用近半年，并多次进行切换演练，运行良好。