淺談秒級故障切換!用MHA輕鬆實現MySQL高可用(一)

MHA簡介服務器

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


MHA架構併發

MHA由MHA Manager和MHA Node組成。以下圖:異步

wKiom1mGoIeS9VJsAAF65FFj3E8143.png


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工做原理

wKiom1mGoLbS9LhmAACDug7w2Gg204.png

當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。

相關文章
相關標籤/搜索