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

標籤：mysql   高可用   mha   

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高可用（三）