【Mysql】MHA的原理

MHA簡介

MHA是由日本人yoshinorim（原就職於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的優勢
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。