MHA簡介服務器
MHA是由日本人youshimaton(原就任於DeNA,現就任於FaceBook)開發的比較成熟的MySQL高可用方案。MHA可以在30秒內實現故障切換,並能在故障切換中,最大可能的保證數據一致性。目前淘寶也正在開發類似產品TMHA,目前已支持一主一從。架構
MHA架構併發
MHA由MHA Manager和MHA Node組成。以下圖:異步
MHA Manageride
運行一些工具,好比masterha_manager工具實現自動監控MySQL Master和實現master故障切換,其它工具實現手動實現master故障切換、在線mater轉移、鏈接檢查等等。一個Manager能夠管理多個master-slave集羣。工具
MHA Node性能
部署在全部運行MySQL的服務器上,不管是master仍是slave。主要做用有三個。spa
Ⅰ、保存二進制日誌線程
若是可以訪問故障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。