MySQL 高可用方案選型

前言：對於每一個想99的公司來講，高可用方案都是不得不考慮的。高可用方案不少，重點在於選擇適合本身的方案。沒有最牛逼的方案，只有最適合本身的方案

 

1、高可用的幾種實現方式
基於主從複製
基於Galera協議
基於NDB引擎
基於中間件/proxy
基於共享存儲
基於主機高可用

在這些可選項中，最多見的就是基於主從複製的方案，其次是基於Galera的方案

 

2、基於主從複製的高可用方案

一、雙節點主從 + keepalived/heartbeat
通常來講，中小型規模的時候，採用這種架構是最省事的。
兩個節點能夠採用簡單的一主一從模式，或者雙主模式，而且放置於同一個VLAN中，在master節點發生故障後，利用keepalived/heartbeat的高可用機制實現快速切換到slave節點。
在這個方案裏，有幾個須要注意的地方：
1>採用keepalived做爲高可用方案時，兩個節點最好都設置成BACKUP模式，避免由於意外狀況下（好比腦裂）相互搶佔致使往兩個節點寫入相同數據而引起衝突；
2>把兩個節點的auto_increment_increment（自增起始值）和auto_increment_offset（自增步長）設成不一樣值。其目的是爲了不master節點意外宕機時，可能會有部分binlog未能及時複製到slave上被應用，從而會致使slave新寫入數據的自增值和原先master上衝突了，所以一開始就使其錯開；固然了，若是有合適的容錯機制能解決主從自增ID衝突的話，也能夠不這麼作；
3>slave節點服務器配置不要太差，不然更容易致使複製延遲。做爲熱備節點的slave服務器，硬件配置不能低於master節點；
4>若是對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7最新版本，利用多線程複製的方式能夠很大程度下降複製延遲；
5>對複製延遲特別敏感的另外一個備選方案，是採用semi sync replication（就是所謂的半同步複製）或者後面會提到的PXC方案，基本上無延遲，不過事務併發性能會有不小程度的損失，須要綜合評估再決定；
6>keepalived的檢測機制須要適當完善，不能僅僅只是檢查mysqld進程是否存活，或者MySQL服務端口是否可通，還應該進一步作數據寫入或者運算的探測，判斷響應時間，若是超過設定的閾值，就能夠啓動切換機制；
7>keepalived最終肯定進行切換時，還須要判斷slave的延遲程度。須要事先定好規則，以便決定在延遲狀況下，採起直接切換或等待何種策略。直接切換可能由於複製延遲有些數據沒法查詢到而重複寫入；
8>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管理集羣，可實現快速檢測切換，以及便捷的節點管理。

 

3、基於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機制。

 

4、其餘高可用方案

基於NDB Cluster，因爲NDB目前仍有很多缺陷和限制，不建議在生產環境上使用；
基於共享存儲，一方面須要不太差的存儲設備，另外共享存儲可也會成爲新的單點，除非採用基於高速網絡的分佈式存儲，相似RDS的應用場景，架構方案就更復雜了，成本也可能更高；
基於中間件(Proxy)，如今可靠的Proxy選擇並很少，並且沒有通用的Proxy，都有有所針對，好比有的專一解決讀寫分離，有的專一分庫分表等等，真正好用的Proxy通常要自行開發；
基於主機高可用，是指採用相似RHCS構建一個高可用集羣后，再部署MySQL應用的方案。老實說，我沒實際用過，但從側面瞭解到這種方案生產上用的並很少，可能也有些侷限性所致吧；

 

PS：原文做者，葉金榮，公衆號：老葉茶館

爲了方便你們交流，本人開通了微信公衆號，和QQ羣291519319。喜歡技術的一塊兒來交流吧