MySQL高可用方案：基於MHA實現的自動故障轉移羣集

經常使用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
是
是

目前自動故障轉移羣集已在咱們的生產環境應用近半年，並屢次進行切換演練，運行良好。