MySQL高可用方案：基於MHA實現的自動故障轉移群集
常用MySQL不同高可用方案的對比（下圖來自官方手冊）
能實現自動數據庫故障轉移的方案只有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
是
是
目前自動故障轉移群集已在我們的生產環境應用近半年，並多次進行切換演練，運行良好。
