MySQL高可用方案選型參考

標籤：

本次專題是 MySQL高可用方案選型，這個專題想必有很多同學感興趣。

高可用的意義以及各種不同高可用等級相應的停機時間我就不必多說了，直接進入主題。

可選MySQL高可用方案

MySQL的各種高可用方案，大多是基於以下幾種基礎來部署的：

1. 基於主從複製；
2. 基於Galera協議；
3. 基於NDB引擎；
4. 基於中介軟體/proxy；
5. 基於共用儲存；
6. 基於主機高可用；

在這些可選項中，最常見的就是基於主從複製的方案，其次是基於Galera的方案，我們重點說說這兩種方案。其餘幾種方案在生產上用的並不多，我們只簡單說下。

基於主從複製的高可用方案雙節點主從 + keepalived/heartbeat

一般來說，中小型規模的時候，採用這種架構是最省事的。
兩個節點可以採用簡單的一主一從模式，或者雙主模式，並且放置於同一個VLAN中，在master節點發生故障後，利用keepalived/heartbeat的高可用機制實現快速切換到slave節點。

在這個方案裡，有幾個需要注意的地方：

• 採用keepalived作為高可用方案時，兩個節點最好都設定成BACKUP模式，避免因為意外情況下（比如腦裂）相互搶佔導致往兩個節點寫入相同資料而引發衝突；
• 把兩個節點的auto_increment_increment（自增起始值）和auto_increment_offset（自增步長）設成不同值。其目的是為了避免master節點意外宕機時，可能會有部分binlog未能及時複製到slave上被應用，從而會導致slave新寫入資料的自增值和原先master上衝突了，因此一開始就使其錯開；當然了，如果有合適的容錯機制能解決主從自增ID衝突的話，也可以不這麼做；
• slave節點伺服器配置不要太差，否則更容易導致複寫延遲。作為熱備節點的slave伺服器，硬體設定不能低於master節點；
• 如果對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7最新版本，利用多線程複製的方式可以很大程度降低複寫延遲；
• 對複寫延遲特別敏感的另一個備選方案，是採用semi sync replication（就是所謂的半同步複製）或者後面會提到的PXC方案，基本上無延遲，不過事務並發效能會有不小程度的損失，需要綜合評估再決定；
• keepalived的檢測機制需要適當完善，不能僅僅只是檢查mysqld進程是否存活，或者MySQL服務連接埠是否可通，還應該進一步做資料寫入或者運算的探測，判斷回應時間，如果超過設定的閾值，就可以啟動切換機制；
• keepalived最終確定進行切換時，還需要判斷slave的延遲程度。需要事先定好規則，以便決定在延遲情況下，採取直接切換或等待何種策略。直接切換可能因為複寫延遲有些資料無法查詢到而重複寫入；
• keepalived或heartbeat自身都無法解決腦裂的問題，因此在進行服務異常判斷時，可以調整判斷指令碼，通過對第三方節點補充檢測來決定是否進行切換，可降低腦裂問題產生的風險。

雙節點主從+keepalived/heartbeat方案架構見下：

圖解：MySQL雙節點（單向/雙向主從複製），採用keepalived實現高可用架構。

多節點主從+MHA/MMM

多節點主從，可以採用一主多從，或者雙主多從的模式。
這種模式下，可以採用MHA或MMM來管理整個叢集，目前MHA應用的最多，優先推薦MHA，最新的MHA也已支援MySQL 5.6的GTID模式了，是個好訊息。
MHA的優勢很明顯：

• 開源，用Perl開發，代碼結構清晰，二次開發容易；
• 方案成熟，故障切換時，MHA會做到較嚴格的判斷，盡量減少資料丟失，保證資料一致性；
• 提供一個通用架構，可根據自己的情況做自訂開發，尤其是判斷和切換操作步驟；
• 支援binlog server，可提高binlog傳送效率，進一步減少資料丟失風險。

不過MHA也有些限制：

• 需要在各個節點間打通ssh信任，這對某些公司安全制度來說是個挑戰，因為如果某個節點被駭客攻破的話，其他節點也會跟著遭殃；
• 內建提供的指令碼還需要進一步補充完善，當然了，一般的使用還是夠用的。

多節點主從+etcd/zookeeper

在大規模節點環境下，採用keepalived或者MHA作為MySQL的高可用管理還是有些複雜或麻煩。
首先，這麼多節點如果沒有採用佈建服務來管理，必然雜亂無章，線上切換時很容易誤操作。
在較大規模環境下，建議採用etcd/zookeeper管理叢集，可實現快速檢測切換，以及便捷的節點管理。

基於Galera協議的高可用方案

Galera是Codership提供的多主要資料同步複製機制，可以實現多個節點間的資料同步複製以及讀寫，並且可保障資料庫的服務高可用及資料一致性。
基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC），目前PXC用的會比較多一些。

PXC的架構見下：

(圖片源自網路)，圖解：在底層採用wsrep介面實現資料在多節點間的同步複製。

 

(圖片源自網路)，圖解：在PXC中，一次資料寫入在各個節點間的驗證/復原流程。

PXC的優點

• 服務高可用；
• 資料同步複製(並發複製)，幾乎無延遲；
• 多個可同時讀寫節點，可實現寫擴充，不過最好事先進行分庫分表，讓各個節點分別寫不同的表或者庫，避免讓galera解決資料衝突；
• 新節點可以自動部署，部署操作簡單；
• 資料嚴格一致性，尤其適合電商類應用；
• 完全相容MySQL；

雖然有這麼多好處，但也有些局限性：

• 只支援InnoDB引擎；
• 所有表都要有主鍵；
• 不支援LOCK TABLE等顯式鎖操作；
• 鎖衝突、死結問題相對更多；
• 不支援XA；
• 叢集輸送量/效能取決於短板；
• 新加入節點採用SST時代價高；
• 存在寫擴大問題；
• 如果並發事務量很大的話，建議採用InfiniBand網路，降低網路延遲；

事實上，採用PXC的主要目的是解決資料的一致性問題，高可用是順帶實現的。因為PXC存在寫擴大以及短板效應，並發效率會有較大損失，類似semi sync replication機制。

其他高可用方案

• 基於NDB Cluster，由於NDB目前仍有不少缺陷和限制，不建議在生產環境上使用；
• 基於共用儲存，一方面需要不太差的存放裝置，另外共用儲存可也會成為新的單點，除非採用基於高速網路的分布式儲存，類似RDS的應用情境，架構方案就更複雜了，成本也可能更高；
• 基於中介軟體(Proxy)，現在可靠的Proxy選擇並不多，而且沒有通用的Proxy，都有有所針對，比如有的專註解決讀寫分離，有的專註分庫分表等等，真正好用的Proxy一般要自行開發；
• 基於主機高可用，是指採用類似RHCS構建一個高可用叢集後，再部署MySQL應用的方案。老實說，我沒實際用過，但從側面瞭解到這種方案生產上用的並不多，可能也有些局限性所致吧；

以DBA們的聰明才智，肯定還有其他我不知道的方案，也歡迎同行們間多多交流。

MySQL高可用方案選型參考