淺談秒級故障切換！用MHA輕鬆實現MySQL高可用（一）

MHA簡介

MHA是由日本人youshimaton（原就任於DeNA，現就任於FaceBook）開發的比較成熟的MySQL高可用方案。MHA可以在30秒內實現故障切換，並能在故障切換中，最大可能的保證數據一致性。目前淘寶也正在開發類似產品TMHA，目前已支持一主一從。

MHA架構

MHA由MHA Manager和MHA Node組成。以下圖：

MHA Manager

運行一些工具，好比masterha_manager工具實現自動監控MySQL Master和實現master故障切換，其它工具實現手動實現master故障切換、在線mater轉移、鏈接檢查等等。一個Manager能夠管理多個master-slave集羣。

MHA Node

部署在全部運行MySQL的服務器上，不管是master仍是slave。主要做用有三個。

Ⅰ、保存二進制日誌

若是可以訪問故障master，會拷貝master的二進制日誌

II、應用差別中繼日誌

從擁有最新數據的slave上生成差別中繼日誌，而後應用差別日誌。

III、清除中繼日誌

在不中止SQL線程的狀況下刪除中繼日誌

MHA工做原理

當master出現故障時，經過對比slave之間I/O線程讀取masterbinlog的位置，選取最接近的slave作爲latestslave。其它slave經過與latest slave對比生成差別中繼日誌。在latest slave上應用從master保存的binlog，同時將latest slave提高爲master。最後在其它slave上應用相應的差別中繼日誌並開始重新的master開始複製。

在MHA實現Master故障切換過程當中，MHA Node會試圖訪問故障的master（經過SSH），若是能夠訪問（不是硬件故障，好比InnoDB數據文件損壞等），會保存二進制文件，以最大程度保證數據不丟失。MHA和半同步複製一塊兒使用會大大下降數據丟失的危險。

 

當前高可用方案

• Heartbeat+DRBD

開銷：須要額外添加處於被動狀態的master server（並不處理應用流量）

性能：爲了實現DRBD複製環境的高可用，innodb-flush-log-at-trx-commit和sync-binlog必須設置爲1，這樣會致使寫性能降低。

一致性：在master上必要的binlog時間可能會丟失，這樣slave就沒法進行復制，致使產生數據一致性問題。

• MySQL Cluster

MySQL Cluster真正實現了高可用，可是使用的是NDB存儲引擎，而且SQL節點有單點故障問題。

• 半同步複製(5.5+)

半同步複製大大減小了「binlog events只存在故障master上」的問題。

在提交時，保證至少一個slave（並非全部的）接收到binlog，所以一些slave可能沒有接收到binlog。

• 全局事務ID

在二進制文件中添加全局事務ID（global transaction id）須要更改binlog格式，在5.1/5.5版本中不支持。

在應用方面有不少方法能夠直線全局事務ID，可是仍避免不了複雜度、性能、數據丟失或者一致性的問題。

• PXC

PXC實現了服務高可用，數據同步時是併發複製。可是僅支持InnoDB引擎，全部的表都要有主鍵。鎖衝突、死鎖問題相對較多等等問題。

 

MHA的優點

一、故障切換快

在主從複製集羣中，只要從庫在複製上沒有延遲，MHA一般能夠在數秒內實現故障切換。9-10秒內檢查到master故障，能夠選擇在7-10秒關閉master以免出現裂腦，幾秒鐘內，將差別中繼日誌（relay log）應用到新的master上，所以總的宕機時間一般爲10-30秒。恢復新的master後，MHA並行的恢復其他的slave。即便在有數萬臺slave，也不會影響master的恢復時間。

DeNA在超過150個MySQL（主要5.0/5.1版本）主從環境下使用了MHA。當mater故障後，MHA在4秒內就完成了故障切換。在傳統的主動/被動集羣解決方案中，4秒內完成故障切換是不可能的。

二、master故障不會致使數據不一致

當目前的master出現故障是，MHA自動識別slave之間中繼日誌（relay log）的不一樣，並應用到全部的slave中。這樣全部的salve可以保持同步，只要全部的slave處於存活狀態。和Semi-Synchronous Replication一塊兒使用，（幾乎）能夠保證沒有數據丟失。

三、無需修改當前的MySQL設置

MHA的設計的重要原則之一就是儘量地簡單易用。MHA工做在傳統的MySQL版本5.0和以後版本的主從複製環境中。和其它高可用解決方法比，MHA並不須要改變MySQL的部署環境。MHA適用於異步和半同步的主從複製。

啓動/中止/升級/降級/安裝/卸載MHA不須要改變（包擴啓動/中止）MySQL複製。當須要升級MHA到新的版本，不須要中止MySQL，僅僅替換到新版本的MHA，而後重啓MHA　Manager就行了。

MHA運行在MySQL 5.0開始的原生版本上。一些其它的MySQL高可用解決方案須要特定的版本（好比MySQL集羣、帶全局事務ID的MySQL等等），但並不只僅爲了master的高可用才遷移應用的。在大多數狀況下，已經部署了比較舊MySQL應用，而且不想僅僅爲了實現Master的高可用，花太多的時間遷移到不一樣的存儲引擎或更新的前沿發行版。MHA工做的包括5.0/5.1/5.5的原生版本的MySQL上，因此並不須要遷移。

四、無需增長大量的服務器

MHA由MHA Manager和MHA Node組成。MHA Node運行在須要故障切換/恢復的MySQL服務器上，所以並不須要額外增長服務器。MHA Manager運行在特定的服務器上，所以須要增長一臺（實現高可用須要2臺），可是MHA Manager能夠監控大量（甚至上百臺）單獨的master，所以，並不須要增長大量的服務器。即便在一臺slave上運行MHA Manager也是能夠的。綜上，實現MHA並沒用額外增長大量的服務。

五、無性能降低

MHA適用與異步或半同步的MySQL複製。監控master時，MHA僅僅是每隔幾秒（默認是3秒）發送一個ping包，並不發送重查詢。能夠獲得像原生MySQL複製同樣快的性能。

六、適用於任何存儲引擎

MHA能夠運行在只要MySQL複製運行的存儲引擎上，並不只限制於InnoDB，即便在不易遷移的傳統的MyISAM引擎環境，同樣可使用MHA。