MySQL高可用方案：基于MHA实现的自动故障转移群集

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

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

所以，对于咱们来讲，在Replication的基础上设计HA方案是最好的选择。

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

因为MySQL复制的异步性（最多半同步），因此，简单的MySQL Replication + 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 是 是 目前自动故障转移群集已在咱们的生产环境应用近半年，并屡次进行切换演练，运行良好。