MySQL復制是異步或者半同步的。當master故障時，一些slave可能並沒有收到最新的relay log，也就意味著每個slave可能處於不同的狀態。手動處理這些一致性問題是小事，因為不修復這些問題，就不能開始復制。但是手動修復這些問題，花費一個小時或更多的時間並不少見。

一主一從

如果架構是一主一從，就不會出現一部分slave的狀態落後於最新的slave的問題。當master出現故障，可以將應用的流量全部發送給新的master（原來的slave）。故障切換很容易解決。但是會有下面的問題。

首先，不能擴展讀流量。在很多情況下，可能會運行一些重要的操作，比如備份、分析查詢、批量處理。這可能會導致slave的性能問題。如果只要一個slave，當這個slave出現故障後，master必須處理所有這些流量。

其次，可用性問題。如果master出現故障，只剩下一臺服務（原來的slave成為主），就成為了單點故障問題。為了創建一個新的slave，需要在線備份，然後存儲到新的slave上並立即啟動slave。但是這些操作通常會花費數小時（甚至是不止一天才能完成復制）。在一些重要的應用上，可能忍受不了數據庫這麽長時間有單點故障問題。並且，在線備份會大大增加master的I/O負載，因此在高峰期進行備份是很危險的。

雙主多從

雙主多從也是常見的架構。如果當前的master出現故障，備用的master就會變為新master。大很多場景下，備用的master都配置為只讀。

但這不總是作為master故障切換解決方案運行的。當目前的master出現故障，余下的slave可能沒有接收到全部的relay log，因此在slave之間解決一致性問題仍需要其它解決方案。

如果不能忍受一致性問題並且還想立即啟動服務。只需要將備用的master作為新的master，並且拋棄剩余的slave。之後再從這個新的master做線上備份創建新的slave。但是這個方法和前面提到的一主一從的發法有同樣的問題。剩余的slave不能進行讀擴展和進行冗余的目的。

另外，使用雙主（一個只讀）並且每個master都至少有一個從也是可能的。

至少一個從可以進行復制，如果目前的master出現故障。但是事實上，很多使用者都不會采用這種架構，因為最大的缺點是復雜性。在這種架構中使用了三層復制。管理三層復制並不容易。例如，如果備用master出現故障，備用master的slave就無法繼續進行復制。很多情況下，必須重新配置備用master和它的slave。重要的是，在這種架構中，必須要使用至少4臺服務器。

心跳+DRBD

使用心跳（Heartbeat）+DRBD+MySQL是非常常見的HA解決方案。但是這個解決方案有一些嚴重的問題。

第一個問題是開銷，特別是想運行大量MySQL復制環境的時候。心跳+DRBD是主用/備用解決方案，因此需要一個不處理任何應用流量的被動（standby）master。被動服務器不能被用來進行讀擴展。通常，你至少需要4臺MySQL服務，一個主動(active)master，一個被動(passive)master，兩個slave。

第二個問題是停機。因為心跳+Heartbeat是active/standby集群，因此如果active server出現故障，故障恢復會發生在passive server上。這可能需要花費很長的時間，特別是沒有用InnoDB插件。即使使用了InnoDB插件，只花費幾分鐘在passive server開始接收訪問連接的情況並不常見。除了故障恢復時間，在故障恢復後，熱身（warm-up）（填充數據到緩沖池）也要花費時間，因為在passive上，數據庫/文件系統緩存是空的。在實際中，需要一個或更多額外的slave來處理足夠的讀流量。在warm-up期間，由於還粗是空的，因此寫性能會顯著下降。

第三個問題是寫性能下降或一致性問題。為了保證active/passive高可用集群運行，在每次commit必須把事務日誌(二進制日誌和InnoDB日誌)刷新到磁盤，因此必須設置innodb-flush-log-at-trx-cmmit=1和sync-binlog=1。但是sync-binlog=1會降低寫性能，因為在當前的MySQL版本fsync()是連續的（如果sync-binlog是1，組提交就會打破）。大多數情況下，不會設置sync-binlog=1。但是如果sync-binlog=1沒有設置，當active master故障，新的master（之前的passive server）可能會丟失已經被發送到slave上的二進制日誌事件。假如，master出現故障，並且slave A接收到mysql-bin.00123的1500位置。如果binlog數據近刷新到1000位置到磁盤，新的master僅只有mysql-bin.00123到1000位置並且創建新的二進制文件mysql-bin.00124。如果出現這種情況，由於新的master沒有mysql-bin.00123的1500位置，slave A就不能進行復制了。

第四個問題是復雜性。對於很多用戶來說，安裝/配置心跳和DRBD是不簡單的。在很多部署環境，配置DRBD經常需要重建系統分區，這在很多情況下是不容易的。另外，也需要在DRBD和Linux內核層有足夠的經驗。如果執行了一個錯誤的命令（比如在passive節點執行了drbd –overwrite-data-of-peer）非常容易損壞生產數據。當使用DRBD，一旦出現磁盤I/O層的問題，對於大多數DBA來說，解決這個問題是很難的。

MySQL集群

MySQL集群真正實現了高可用解決方案，但是必須使用NDB存儲引擎。大多數情況下都是使用InnoDB，因此無法使用MySQL集群的優勢。

• 半同步復制

半同步復制大大降低了”binlog僅存在故障master上”的風險。這對避免數據的丟失有很大的幫助。但是半同步復制並沒有解決一致性問題。半同步復制保證在master提交時至少有一個（並不是所有）slave接收到binlog事件。仍有可能一些slave沒有接收到binlog事件。如果沒有將最新的slave上的relay log應用到非最新的slave上，slave就無法處於一致性狀態。

MHA解決了一致性問題，因此通過將半同步復制和MHA一起使用，幾乎沒有數據丟失和slave保持一直就能實現。

全局事務ID（GTID）

全局事務ID的目的和MHA想要實現的是基本相同的，但是全局事務ID包括的更多。MHA只能支持兩層復制，但是全局事務ID可以支持很多層復制的環境，因此即使第二層復制故障了，仍然可以恢復三層復制。

從MySQL5.6開始就開始支持GTID了。Oracle的官方工具mysqlfailover支持帶GTID的master故障切換。從MHA的0.56版本開始，也支持基於GTID的故障切換。MHA會自動檢測mysqld是否在GTID運行，如果GTID開啟，MHA就實現帶GTID的故障切換，如果沒有啟用，MHA就使用基於relay log的故障切換。

本文出自 “一杯水” 博客，請務必保留此出處http://6528161.blog.51cto.com/6518161/1954483

淺談秒級故障切換！用MHA輕松實現MySQL高可用（三）