MySQL高可用方案選型參考
本次專題是 MySQL高可用方案選型 ，這個專題想必有很多同學感興趣。
高可用的意義以及各種不同高可用等級相應的停機時間我就不必多說了，直接進入主題。
可選MySQL高可用方案
MySQL的各種高可用方案，大多是基于以下幾種基礎來部署的：
- 基于主從復制；
- 基于Galera協議；
- 基于NDB引擎；
- 基于中間件/proxy；
- 基于共享存儲；
- 基于主機高可用；
在這些可選項中，最常見的就是基于主從復制的方案，其次是基于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們的聰明才智，肯定還有其他我不知道的方案，也歡迎同行們間多多交流。