在网上,baidu一下，你就能得到一堆heartbeat mysql或者pacemaker mysql实现HA（高可用性）的文章。其实你想实现HA(高可用性)与数据完整性的统一并不容易，下面先对一些已存在的HA方案进行一个简单回顾和评论
- 方案1： 心跳(heartbeat)和复制(replication)
数据库一个为master,一个为slave，所有对master数据修改会通过replication复制到slave。两台机器只有一个通过floating IP对外提供服务。 当master出问题时，slave能检测到heartbeat失败，floatingIP 切换到原有的slave。两数据库必须同时启动
优点：
充分利用mysql复制功能
能做到master出问题时自动切换
手动failover能做到0数据丢失
缺点：
自动Failover时可能会有数据丢失，有一部分数据可能没有复杂到slave
需要额外技术保证heartbeat和replication的畅通。
如果有两台以上application serve，就有出现splitbrain问题。
改善：
可以使用linux IP bonding等技术保证heartbeat和replication之间链路的可靠性。
- 方案2：heartbeat + drbd
与上一方案类似，也采用floating/virtual IP和heartbeat。不同点就是同时只有一个mysql处于running状态，另外一台机器在10.10.10.20 failover之前根本就没有起mysql。两数据库不能同时启动
优点：
利用廉价的设备替换共享存贮方案，穷人的选择
能做到master出问题时自动切换
手动failover能做到0数据丢失
缺点：
自动Failover时可能会有数据丢失， 10.10.10.20宕机时可能有drbd数据同步到另外一台机器。
需要额外技术保证heartbeat和drbd的畅通。
如果有两台以上application serve，就有出现splitbrain问题。
备用机需要比第一种更长时间切换。它必须首先mountdrbd分区，然后启动mysql。
改善：
可以使用linux IP bonding等技术保证heartbeat和drbd之间链路的可靠性。
- 方案3：heartbeat + 共享存储
与方案2高度类似，只是用NAS或者SAN等替换了廉价的drbd方案。两数据库不能同时启动
优点：
可以做到0数据丢失，也不需要在网络中复制数据
能做到master出问题时自动切换
缺点：
成本相对较高。
需要额外技术保证heartbeat的畅通。
有可能出现split brain问题。但是可以通过技术手段避免
备用机需要比第一种更长时间切换。它必须首先启动mysql。
改善：
可以使用linux IP bonding等技术保证heartbeat之间链路的可靠性。
注意不要让共享存贮成为新的单点故障点。
当前我们实现的方案是primary节点定期写时间戳和机器名到共享存贮。secondary节点只有在primary在超过某一时间段没有更新时间戳的情况下才准备failover。如果primary检测到secondary上的时间戳需要立即停止服务。
- 方案4：mysql 集群
优点：
内存数据库，本身就有高可用性，请求响应快，适合实时应用
MySQL ClusterManager能实现帮助自动化管理，故障的检测和恢复，高可用运维
能实现地理冗余
缺点：
由于事务提交是内存同步，有下电丢数据的风险
需要自己处理地理冗余情况下的split brain
改善：
可以额外开发充分利用cluster地理冗余特性，比方地理failover
-
总结：
1，如果你是银行结算系统，任何数据的不一致都是不可接受的，可以考虑共享存贮，如果你在乎并发实时性，可以考虑mysql cluster。如果你是穷人，可以选择drbd。
2，不管哪一种方案，都需要自己考虑split brain。
3，不管哪一种方案，我们都可以利用network bonding技术实现网络层的冗余。这将在后面的文章中继续介绍
4，heartbeat或者pacemaker几乎是所有HA开源方案的第一选择
参考： http://www.doc88.com/p-695588579829.html