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

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的故障切換。