常用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停止響應
資料丢失
由于資料丢失,無法自動重新同步
複制延遲（未執行日志500M）＋主機CentOS停止響應）
2.5～2.7m