MHA是MySQL High Available的縮寫，一般指一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證資料庫系統的高可用。

         MHA易於安裝和部署，不需要改變現有部署，也不影響伺服器效能 (1 ping/3s)，而且可以完全部署到Slave上，節約了新伺服器的成本。

         如此輕量的部署，就能提供自動監控master和故障轉移 (downtime 10~30s)，保障主從資料的一致性 (即使master crash)，並適用於MySQL的任何主從儲存引擎。真是超值啊！

         還支援線上切換master，只需要很短的時間(0.5~2s)，此時僅僅阻塞寫操作，並不影響讀操作

MHA優點

master自動監控和故障轉移

         在當前已存在的主從複製環境中，MHA可以監控master主機故障，並且故障自動轉移。

         MHA秒級別故障轉移：9-12秒監測到主機故障，任選7秒鐘關閉電源主機避免腦裂，接下來apply差異relay logs，註冊到新的master。通常整個downtime只需要10-30秒。

         即使有一些slave沒有接受新的relaylog events，MHA也會從最新的slave自動識別差異的relay log events，並apply差異的event到其他slaves。因此所有的

         另外，在配置檔案裡可以配置一個slave優先成為master。因為MHA修復了slave之間的一致性，dba就不用去處理一致性問題。

         當遷移新的master之後，並行恢復其他slave。即使有成千上萬的slave,也不會影響恢復master時間，slave也很快完成。

         ForExample: DeNA公司在150+主從環境中用MHA。當其中一個master崩潰，MHA只要4秒就完成故障轉移，這是主動/被動叢集解決方案無法完成的。

保障主從資料的一致性

         即使mastercrash，MHA會自動識別slave

 P.S. 但不能保證0丟失。

非互動式故障轉移

         也可以支援不監控master，自動/手動故障轉移。這個特性很有用，特別是你已經安裝了其他軟體監控master。比如，用Pacemaker(Heartbeat)監測master故障和vip接管，用MHA故障轉移和slave提升。

線上切換master到不同主機

         在很多情況下，有必要將master轉移到其他主機上（如替換raid控制器，提升master機器硬體等等）。這並不是master崩潰，但是計劃維護必須去做。計劃維護導致downtime，必須儘可能快的恢復。

         快速的master切換和優雅的阻塞寫操作是必需的，MHA也不例外，其中阻塞寫操作一般在0.5-2秒。在很多情況下0.5-2秒downtime是可以接受的，並且即使不在計劃維護視窗。這意味著當需要更換更快機器，升級高版本時，DBA可以很容易採取動作。

MHA部署不影響當前環境設定

         MHA最重要的一個設計理念就是儘可能使用簡單。

         使用與5.0+以上主從環境，其他HA方案需要改變MySQL部署設定；而MHA則不需要做這些配置，同步和半同步環境都可以用。

         啟動/停止/升級/降級/安裝/解除安裝 MHA都不用改變MySQL主從（如啟動/停止）。當要升級MHA到新版本時，不需要停止MySQL，僅僅更新HMA版本，重啟MHA Manger即可。

不增加伺服器費用

         MHA包含MHA Manager和MHA Node。MHA node執行在每臺MySQL伺服器上，Manager可以單獨部署一臺機器，可以監控100+的master，總伺服器數量不會有太大增加。而且Manager也可以執行在slaves中的一臺機器上。

效能無影響

         當監控master，MHA只是幾秒鐘（預設3秒）傳送ping包，不傳送大的查詢。主從複製效能不受影響

適用任何儲存引擎

         MHA不僅僅適用於事務安全的innodb引擎，而是所有主從引擎都適用。

與其他HA方案比較

手動處理

         MySQL的複製有同步，非同步和半同步三種模式，一般為了提高效能都不會採用同步的方式。當master崩潰時，很有可能一些slave還沒有接受最新的relay log events，這意味著每一個slave都相互處在不同的狀態。

         人為地修復一致性的問題會非常麻煩。而且由於一致性的異常，主從也不能正常啟動 (duplicate key error)。在手動重啟的情況下，往往花費1個小時是很正常的，這成本就太大了。

單一主從

         要解決上述一致性的問題，可以只部署單一主從。這樣一些slave 落後與其他slave的情況將不會發生。其中一個master崩潰，可以輕鬆的讓應用轉移到一個新的master上面，提供對外服務，故障遷移很簡單。

         單一主從簡單高效，非常便於維護。就是負載量不大，隨著應用的擴張，單一必然無法支援。   【適合的就是最好的】

一主一備，多從 (雙主多從) Master,one candidate master, and multiple slaves

         雙主多從的架構也很常見。主master掛掉，備用master將接替主master提供服務。某些情況配置為多主架構。

         但這只是作為master故障轉移方案。而資料一致性還沒得到解決，當前master掛掉，剩餘slave不一定接受全部relay log events。

         這種架構使用廣泛，其中一個通用的方案Pecemaker(Heartbeat)+DRBD+MySQL：

雙master，其中一個master只讀，每個master都至少有一個slave。

                  M(RW)--M2(R)

                      |              |

                  S(R)      S2(R)

         但也會存在下面幾個問題：

l  1 費用，特別是跑大量主從環境。Pecemaker+DRBD是主動/被動的解決方案，因此需要一臺被動伺服器對外不提供任何應用服務。基本的需要四臺MySQL伺服器，one active master，one passive master，two slaves。

l  2 宕機時間(downtime)。Pacemaker+DRBD是主備叢集，主master掛掉，備用master啟用。這可能花費長的時間，特別是沒有用innodb plugin。即使用innodb plugin，花費幾分鐘開始在備用master上接受連線也不尋常。另外，因為備用master上資料/檔案快取是空的，恢復時間，熱身(填充資料到data buffer pool)花費不可忽視的時間。實踐中，需要一臺或更多slave提供足夠的讀服務。在熱身時間內，空快取導致寫效能降低

l  3 寫效能下降和一致性問題。為了讓主動/被動叢集真正的工作，每次提交(commit)後，必須重新整理事務日誌(binary log和innodb log)，會降低寫效能。另外，slave和備份master的同步機制(刷日誌)不一樣，導致活動master crash的時候，slave和備份master可能會出現一致性的問題。

MySQL Cluster

         MySQL cluster是真正的高可用解決方案，但是必須得用NDB儲存引擎。如果你用innodb，將不能發揮MySQL cluster叢集優勢。

半同步複製 Semi-Synchronous Replication

         半同步複製大大降低了binlogevent僅僅存在於崩潰master上的這種風險。這非常有用的能避免資料丟失。但是半同步不能解決所有一致性問題，只能保證一個（不是所有）slave接受到master端的commit的binlog events，其他slave也許還沒有接受全部的binlog events。

         所以，如果不能從新的slave來apply不同的binlogevents到其他slave上，也就不能保證相互一致性。

Global Transaction ID

         GlobalTransactionID所要達到的目的跟MHA相同，但它覆蓋更多。MHA只是兩級複製，但是global transaction id覆蓋任何級別的複製環境，即使第兩級複製失敗，dba也能覆蓋第三級。Check Google'sglobal transaction id project for details。

         原文出處：http://blog.csdn.net/aeolus_pu/article/details/9127897