整理歸納五大常見的MySQL高可用方案

本篇文章為大家帶來了關於mysql的相關知識，其中主要介紹了關於常見的高可用方案的相關問題，這裡只討論常用高可用方案的優缺點以及高可用方案的選型，下面一起來看一下，希望對大家有幫助。

推薦學習：mysql影片教學

#1.概述

我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：

• 如果資料庫發生了宕機或意外中斷等故障，能盡快恢復資料庫的可用性，盡可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。
• 用作備份、只讀副本等功能的非主節點的資料應該和主節點的資料即時或最終保持一致。
• 當業務發生資料庫切換時，切換前後的資料庫內容應一致，不會因為資料缺失或資料不一致而影響業務。

關於對高可用的分級在這裡我們不做詳細的討論，這裡只討論常用高可用方案的優缺點以及高可用方案的選型。

2. 高可用方案

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

使用雙節點資料庫，建立單向或雙向的半同步複製。在5.7以後的版本中，由於lossless replication、logical多執行緒複製等一些欄位新特性的引入，使得MySQL原生半同步複製更加可靠。

常見架構如下：

通常會和proxy、keepalived等第三方軟體同時使用，也就是可以用來監控資料庫的健康，又可以執行一系列管理指令。如果主庫發生故障，切換到備庫後仍可繼續使用資料庫。

優點：

• 架構比較簡單，使用原生半同步複製作為資料同步的依據；
• 雙節點，沒有主機宕機後的選主問題，直接切換即可；
• 雙節點，需求資源少，部署簡單；

# 缺點：

• 完全依賴半同步複製，如果半同步複製退化為非同步複製，資料一致性無法保證；
• 需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步複製最佳化

#半同步複製機制是可靠的。如果半同步複製一直是生效的，那麼便可以認為資料是一致的。但由於網路波動等一些客觀原因，導致半同步複製發生逾時而切換為非同步複製，那麼這時便不能保證資料的一致性。所以盡可能的保證半同步複製，便可提高資料的一致性。

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

可參考的最佳化方案如下：

2.2.1. 雙通道複製

半同步複製由於發生逾時後，複製斷開，當再次建立起複製時，同時建立兩個通道，其中一條半同步複製通道從目前位置開始複製，保證從機知道目前主機執行的進度。另外一條非同步複製通道開始追補從機落後的資料。當非同步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。

2.2.2. binlog檔案伺服器

#建置兩個半同步複製通道，其中連接檔案伺服器的半同步通道正常情況下不啟用，當主從的半同步複製發生網路問題退化後，啟動與檔案伺服器的半同步複製頻道。當主從半同步複製恢復後，關閉與檔案伺服器的半同步複製通道。

優點：

雙節點，需求資源少，部署簡單；
架構簡單，沒有選主的問題，直接切換即可;
相較於原生複製，優化後的半同步複製更能確保資料的一致性。

缺點：

需要修改核心原始碼或使用mysql通訊協定。需要對源碼有一定的了解，並且能做一定程度的二次開發。
依舊依賴半同步複製，沒有從根本解決資料一致性問題。

2.3. 高可用架構最佳化

將雙節點資料庫擴展到多節點資料庫，或是多節點資料庫叢集。可以依照自己的需求選擇一主兩從、一主多從或多主多從的集群。

由於半同步複製，存在接收到一個從機的成功應答即認為半同步複製成功的特性，所以多從半同步複製的可靠性要優於單從半同步複製的可靠性。且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是比雙節點架構好。

但是由於資料庫數量較多，所以需要資料庫管理軟體來確保資料庫的可維護性。可以選擇MMM、MHA或各個版本的proxy等等。常見方案如下：

2.3.1. MHA 多節點叢集

MHA Manager會定時偵測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程式完全透明。

MHA Node運行在每台MySQL伺服器上，主要功能是切換時處理二進位日誌，確保切換盡量少丟資料。

MHA也可以擴展到如下的多節點叢集：

優點：

可以進行故障的自動偵測與轉移;
可擴展性較好，可以根據需要擴展MySQL的節點數量和結構;
相比於雙節點的MySQL複製，三節點/多節點的MySQL發生不可用的機率更低

##缺點：

至少需要三節點，相對於雙節點需要更多的資源;

邏輯較為複雜，發生故障後排查問題，定位問題更加困難;
資料一致性仍靠原生半同步複製保證，仍然存在資料不一致的風險;
可能因為網路分區發生腦裂現象;

##2.3.2. zookeeper proxy

Zookeeper使用分散式演算法保證集群資料的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分區現象的產生。

優點：

較好的保證了整個系統的高可用性，包括proxy、MySQL;

擴充功能較好，可以擴充為大規模集群;

缺點：

資料一致性仍然依賴原生的mysql半同步複製;

引入zk，整個系統的邏輯變得更加複雜;

2.4. 共享儲存

共享儲存實現了資料庫伺服器和儲存裝置的解耦，不同資料庫之間的資料同步不再依賴MySQL的原生複製功能，而是透過磁碟資料同步的手段，來保證資料的一致性。

2.4.1. SAN共享儲存

SAN的概念是允許儲存設備和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連接，透過此連接實現資料的集中式儲存。常用架構如下：

使用共用儲存時，MySQL伺服器能夠正常掛載檔案系統並操作，如果主庫發生宕機，備庫可以掛載相同的檔案系統，保證主庫和備庫使用相同的資料。
優點：

兩個節點即可，部署簡單，切換邏輯簡單；

很好的保證資料的強一致性；

不會因為MySQL的邏輯錯誤發生資料不一致的情況；

缺點：

需要考慮共享儲存的高可用；

價格昂貴；

2.4.2. DRBD磁碟複製

DRBD是一種基於軟體、基於網路的區塊複製儲存解決方案，主要用於對伺服器之間的磁碟、分割區、邏輯磁碟區等進行資料鏡像，當使用者將資料寫入本機磁碟時，也會將資料傳送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠端主機(備節點)的資料就可以保證即時同步。常用架構如下：

當本地主機出現問題，遠端主機上還保留著一份相同的數據，可以繼續使用，並保證了資料的安全。

DRBD是linux核心模組實現的快速等級的同步複製技術，可以與SAN達到相同的共享儲存效果。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

相較於SAN儲存網絡，價格低廉；

保證資料的強一致性；

缺點：

對io效能影響較大；

從函式庫不提供讀取操作；

2.5. 分散式協定

分散式協定可以很好解決資料一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

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

優點：

全部使用官方元件，不依賴第三方軟體；
可以實現資料的強一致性；

缺點：

國內使用的較少；
配置較複雜，需要使用NDB儲存引擎，與MySQL常規引擎有一定差異；
至少三節點;

2.5.2. Galera

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

優點：

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

缺點：

需要為原生MySQL節點打wsrep補丁
只支持innodb儲存引擎
至少三節點；

2.5.3. POAXS

Paxos 演算法解決的問題是分散式系統如何就某個值（決議）達成協議。這個演算法被認為是同類演算法中最有效的。 Paxos與MySQL結合可以實現在分散式的MySQL資料的強一致性。常見架構如下：

優點：

多主寫入，無延遲複製，能保證資料強一致性；
有成熟理論基礎；
自動故障轉移，自動新增、剔除節點；

缺點：

只支援innodb儲存引擎
至少三節點;

3. 總結

隨著人們對資料一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分散式資料一致性的問題，如MySQL本身的最佳化、MySQL叢集架構的最佳化、Paxos、Raft、 2PC演算法的引入等等。

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

隨著官方MySQL Group Replication的GA，使用分散式協定來解決資料一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。

推薦學習：mysql影片教學

#

以上是整理歸納五大常見的MySQL高可用方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！