五大常見的MySQL高可用方案

本文來自：https://zhuanlan.zhihu.com/p/25960208

UCloud雲計算 

1. 概述

咱們在考慮MySQL數據庫的高可用的架構時，主要要考慮以下幾方面：

• 若是數據庫發生了宕機或者意外中斷等故障，能儘快恢復數據庫的可用性，儘量的減小停機時間，保證業務不會由於數據庫的故障而中斷。
• 用做備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。
• 當業務發生數據庫切換時，切換先後的數據庫內容應當一致，不會由於數據缺失或者數據不一致而影響業務。

關於對高可用的分級在這裏咱們不作詳細的討論，這裏只討論經常使用高可用方案的優缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步複製

使用雙節點數據庫，搭建單向或者雙向的半同步複製。在5.7之後的版本中，因爲lossless replication、logical多線程複製等一些列新特性的引入，使得MySQL原生半同步複製更加可靠。

常見架構以下：

一般會和proxy、keepalived等第三方軟件同時使用，便可以用來監控數據庫的健康，又能夠執行一系列管理命令。若是主庫發生故障，切換到備庫後仍然能夠繼續使用數據庫。

優勢：

1. 架構比較簡單，使用原生半同步複製做爲數據同步的依據；
2. 雙節點，沒有主機宕機後的選主問題，直接切換便可；
3. 雙節點，需求資源少，部署簡單；

缺點：

1. 徹底依賴於半同步複製，若是半同步複製退化爲異步複製，數據一致性沒法獲得保證；
2. 須要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步複製優化

半同步複製機制是可靠的。若是半同步複製一直是生效的，那麼即可以認爲數據是一致的。可是因爲網絡波動等一些客觀緣由，致使半同步複製發生超時而切換爲異步複製，那麼這時便不能保證數據的一致性。因此儘量的保證半同步複製，即可提升數據的一致性。

該方案一樣使用雙節點架構，可是在原有半同複製的基礎上作了功能上的優化，使半同步複製的機制變得更加可靠。

可參考的優化方案以下：

2.2.1. 雙通道複製

半同步複製因爲發生超時後，複製斷開，當再次創建起復制時，同時創建兩條通道，其中一條半同步複製通道從當前位置開始複製，保證從機知道當前主機執行的進度。另一條異步複製通道開始追補從機落後的數據。當異步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。

2.2.2. binlog文件服務器

搭建兩條半同步複製通道，其中鏈接文件服務器的半同步通道正常狀況下不啓用，當主從的半同步複製發生網絡問題退化後，啓動與文件服務器的半同步複製通道。當主從半同步複製恢復後，關閉與文件服務器的半同步複製通道。

優勢：

1. 雙節點，需求資源少，部署簡單；
2. 架構簡單，沒有選主的問題，直接切換便可;
3. 相比於原生複製，優化後的半同步複製更能保證數據的一致性。

缺點：

1. 須要修改內核源碼或者使用mysql通訊協議。須要對源碼有必定的瞭解，並能作必定程度的二次開發。
2. 依舊依賴於半同步複製，沒有從根本上解決數據一致性問題。

2.3. 高可用架構優化

將雙節點數據庫擴展到多節點數據庫，或者多節點數據庫集羣。能夠根據本身的須要選擇一主兩從、一主多從或者多主多從的集羣。

因爲半同步複製，存在接收到一個從機的成功應答即認爲半同步複製成功的特性，因此多從半同步複製的可靠性要優於單從半同步複製的可靠性。而且多節點同時宕機的概率也要小於單節點宕機的概率，因此多節點架構在必定程度上能夠認爲高可用性是好於雙節點架構。

可是因爲數據庫數量較多，因此須要數據庫管理軟件來保證數據庫的可維護性。能夠選擇MMM、MHA或者各個版本的proxy等等。常見方案以下：

2.3.1. MHA+多節點集羣

MHA Manager會定時探測集羣中的master節點，當master出現故障時，它能夠自動將最新數據的slave提高爲新的master，而後將全部其餘的slave從新指向新的master，整個故障轉移過程對應用程序徹底透明。

MHA Node運行在每臺MySQL服務器上，主要做用是切換時處理二進制日誌，確保切換儘可能少丟數據。

MHA也能夠擴展到以下的多節點集羣：

優勢：

1. 能夠進行故障的自動檢測和轉移;
2. 可擴展性較好，能夠根據須要擴展MySQL的節點數量和結構;
3. 相比於雙節點的MySQL複製，三節點/多節點的MySQL發生不可用的機率更低

缺點：

1. 至少須要三節點，相對於雙節點須要更多的資源;
2. 邏輯較爲複雜，發生故障後排查問題，定位問題更加困難;
3. 數據一致性仍然靠原生半同步複製保證，仍然存在數據不一致的風險;
4. 可能由於網絡分區發生腦裂現象;

2.3.2. zookeeper+proxy

Zookeeper使用分佈式算法保證集羣數據的一致性，使用zookeeper能夠有效的保證proxy的高可用性，能夠較好的避免網絡分區現象的產生。

優勢：

1. 較好的保證了整個系統的高可用性，包括proxy、MySQL;
2. 擴展性較好，能夠擴展爲大規模集羣;

缺點：

1. 數據一致性仍然依賴於原生的mysql半同步複製;
2. 引入zk，整個系統的邏輯變得更加複雜;

2.4. 共享存儲

共享存儲實現了數據庫服務器和存儲設備的解耦，不一樣數據庫之間的數據同步再也不依賴於MySQL的原生複製功能，而是經過磁盤數據同步的手段，來保證數據的一致性。

2.4.1. SAN共享儲存

SAN的概念是容許存儲設備和處理器（服務器）之間創建直接的高速網絡（與LAN相比）鏈接，經過這種鏈接實現數據的集中式存儲。經常使用架構以下：

使用共享存儲時，MySQL服務器可以正常掛載文件系統並操做，若是主庫發生宕機，備庫能夠掛載相同的文件系統，保證主庫和備庫使用相同的數據。

優勢：

1. 兩節點便可，部署簡單，切換邏輯簡單；
2. 很好的保證數據的強一致性；
3. 不會由於MySQL的邏輯錯誤發生數據不一致的狀況；

缺點：

1. 須要考慮共享存儲的高可用；
2. 價格昂貴；

2.4.2. DRBD磁盤複製

DRBD是一種基於軟件、基於網絡的塊複製存儲解決方案，主要用於對服務器之間的磁盤、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁盤時，還會將數據發送到網絡中另外一臺主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就能夠保證明時同步。經常使用架構以下：

當本地主機出現問題，遠程主機上還保留着一份相同的數據，能夠繼續使用，保證了數據的安全。

DRBD是linux內核模塊實現的快級別的同步複製技術，能夠與SAN達到相同的共享存儲效果。

優勢：

1. 兩節點便可，部署簡單，切換邏輯簡單；
2. 相比於SAN儲存網絡，價格低廉；
3. 保證數據的強一致性；

缺點：

1. 對io性能影響較大；
2. 從庫不提供讀操做；

2.5. 分佈式協議

分佈式協議能夠很好解決數據一致性問題。比較常見的方案以下：

2.5.1. MySQL cluster

MySQL cluster是官方集羣的部署方案，經過使用NDB存儲引擎實時備份冗餘數據，實現數據庫的高可用性和數據一致性。

優勢：

1. 所有使用官方組件，不依賴於第三方軟件；
2. 能夠實現數據的強一致性；

缺點：

1. 國內使用的較少；
2. 配置較複雜，須要使用NDB儲存引擎，與MySQL常規引擎存在必定差別；
3. 至少三節點；

2.5.2. Galera

基於Galera的MySQL高可用集羣， 是多主數據同步的MySQL集羣解決方案，使用簡單，沒有單點故障，可用性高。常見架構以下：

優勢：

1. 多主寫入，無延遲複製，能保證數據強一致性；
2. 有成熟的社區，有互聯網公司在大規模的使用；
3. 自動故障轉移，自動添加、剔除節點；

缺點：

1. 須要爲原生MySQL節點打wsrep補丁
2. 只支持innodb儲存引擎
3. 至少三節點；

2.5.3. POAXS

Paxos 算法解決的問題是一個分佈式系統如何就某個值（決議）達成一致。這個算法被認爲是同類算法中最有效的。Paxos與MySQL相結合能夠實如今分佈式的MySQL數據的強一致性。常見架構以下：

優勢：

1. 多主寫入，無延遲複製，能保證數據強一致性；
2. 有成熟理論基礎；
3. 自動故障轉移，自動添加、剔除節點；

缺點：

1. 只支持innodb儲存引擎
2. 至少三節點；

3. 總結

隨着人們對數據一致性的要求不斷的提升，愈來愈多的方法被嘗試用來解決分佈式數據一致性的問題，如MySQL自身的優化、MySQL集羣架構的優化、Paxos、Raft、2PC算法的引入等等。

而使用分佈式算法用來解決MySQL數據庫數據一致性的問題的方法，也愈來愈被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等愈來愈多的被大規模使用。

隨着官方MySQL Group Replication的GA，使用分佈式協議來解決數據一致性問題已經成爲了主流的方向。指望愈來愈多優秀的解決方案被提出，MySQL高可用問題能夠被更好的解決。