簡介

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，另外一臺充當從庫，因為至

工作架構

展示瞭如何通過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環境部署

更加精彩部署篇點選連結：https://www.cnblogs.com/brianzhu