MySQL高可用方案--MHA原理

簡介

MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就任於Facebook公司）開發，是日本的一位
MySQL專家採用Perl語言編寫的一個腳本管理工具，該工具僅適用於MySQLReplication（二層）環境，目的在於維持Master主庫的高可用性。是一套優秀的做爲MySQL高可用性
環境下故障切換和主從提高的高可用軟件。在MySQL故障切換過程當中，MHA能作到在0~30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換的過程當中，MHA能在最大程度上
保證數據的一致性，以達到真正意義上的高可用。

MHA是自動的master故障轉移和Slave提高的軟件包.它是基於標準的MySQL複製(異步/半同步).該軟件由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。
1）MHA Manager能夠單獨部署在一臺獨立的機器上管理多個master-slave集羣，也能夠部署在一臺slave節點上。MHA Manager會定時探測集羣中的node節點,當發現master
出現故障的時候,它能夠自動將具備最新數據的slave提高爲新的master,而後將全部其它的slave導向新的master上.整個故障轉移過程對應用程序是透明的。
2）MHA Node運行在每臺MySQL服務器上，它經過監控具有解析和清理logs功能的腳原本加快故障轉移的。

在MHA自動故障切換過程當中，MHA試圖從宕機的主服務器上保存二進制日誌，最大程度的保證數據的不丟失，但這並不老是可行的。例如，若是主服務器硬件故障或沒法經過ssh訪問，
MHA無法保存二進制日誌，只進行故障轉移而丟失了最新的數據。使用MySQL 5.5或者之後的版本的半同步複製，能夠大大下降數據丟失的風險。MHA能夠與半同步複製結合起來。若是隻有一個slave
已經收到了最新的二進制日誌，MHA能夠將最新的二進制日誌應用於其餘全部的slave服務器上，所以能夠保證全部節點的數據一致性。

目前MHA主要支持一主多從的架構，要搭建MHA,要求一個複製集羣中必須最少有三臺數據庫服務器，一主二從，即一臺充當master，一臺充當備用master，另一臺充當從庫，由於至
少須要三臺服務器，出於機器成本的考慮，淘寶也在該基礎上進行了改造，目前淘寶TMHA已經支持一主一從。

工做架構

展現瞭如何經過MHA Manager管理多組主從複製。能夠將MHA工做原理總結爲以下：

具體的工做流程以下:

相較於其它HA軟件，MHA的目的在於維持MySQL Replication中Master庫的高可用性，其最大特色是能夠修復多個Slave之間的差別日誌，最終使全部Slave保持數據一致，
而後從中選擇一個充當新的Master，並將其它Slave指向它。工做流程主要以下：
1）從宕機崩潰的master保存二進制日誌事件（binlog events）;
2）識別含有最新更新的slave；
3）應用差別的中繼日誌（relay log）到其餘的slave；
4）應用從master保存的二進制日誌事件（binlog events）；
5）提高一個slave爲新的master；
6）使其餘的slave鏈接新的master進行復制；

工做原理

 

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

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

優點

1）故障切換快
在主從複製集羣中，只要從庫在複製上沒有延遲，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秒內完成故障切換是不可能的。

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

3）無需修改當前的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上，因此並不須要遷移。

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

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

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

軟件架構

MHA軟件的架構：由兩部分組成，Manager工具包和Node工具包
Manager工具包主要包括如下幾個工具：
masterha_check_ssh      檢查MHA的SSH配置狀態
masterha_check_repl     檢查MySQL複製的狀態
masterha_check_status   檢查MHA當前的運行狀態
masterha_manger         啓動MHA
masterha_master_monitor 檢測master是否宕機
masterha_master_switch  控制故障轉移(手動或者自動)
masterha_conf_host      添加或者刪除配置的server信息

Node工具包（這些工具一般由MHA Manager的腳本觸發，無需人爲操做）主要包括如下幾個工具：
save_binary_logs        保存和複製master的二進制日誌
apply_diff_relay_logs   識別差別的中繼日誌事件並將其差別的事件應用於其餘的slave服務器
filter_mysqlbinlog      去除沒必要要的ROLLBACK事件(MHA已經不在使用這個工具了)
purge_relay_logs        清除中繼日誌(不會阻塞SQL線程)

MHA如何保持數據的一致性呢？主要經過MHA node的如下幾個工具實現，可是這些工具由mha manager觸發：
save_binary_logs        若是master的二進制日誌能夠存取的話，保存複製master的二進制日誌，最大程度保證數據不丟失
apply_diff_relay_logs   相對於最新的slave，生成差別的中繼日誌並將全部差別事件應用到其餘全部的slave

注意：
對比的是relay log，relay log越新就越接近於master，才能保證數據是最新的。
purge_relay_logs        刪除中繼日誌而不阻塞sql線程

MHA環境部署

更加精彩部署篇點擊連接：http://www.javashuo.com/article/p-woqonius-k.html