MySQL是資料庫領域當之無愧的霸主之一，其在各行各業被廣泛應用，隨著廣泛使用，對於MySQL本身的高可用性的要求就是不可避免的話題，而MySQL的高可用方案也隨著MySQL功能的完善經歷了多次升級，本文將對MySQL的各種高可用架構進行分析，以此來了解架構的演進。

冗餘是高可用設計的核心

高可用的核心是避免單點故障（SPOF），而避免單點故障的最經典的解決方案是增加冗餘。

不同的高可用方案在冗餘方式和冗餘的程度上有所差別。

冗餘方式上面，有些是在底層儲存上進行冗餘，有些是對整個主機進行冗餘，有些是跨IDC的冗餘。

冗餘程度上面，有些是災備級別允許一定程度的資料丟失，有些也是要求資料的強一致性。

MySQL的各種高可用方案的核心就是圍繞著冗餘的設計展開。

MySQL複製技術發展史

MySQL的高可用方案基於MySQL的複製技術，複製技術的核心就是增加一個MySQL節點的冗餘。

1. MySQL Replication引入

2000年，MySQL 3.23.15版本引入了MySQL Replication技術，一經推出就得到了較為廣泛的使用。Replication是一種非同步的資料複製機制，實現的是近實時的資料同步效果。此時的Replicaton主要透過兩個執行緒實現，一個在Master節點，一個在Slave節點。Slave首先透過Master獲取到資料變動的event，然後將這個event在Slave節點進行replay重放。

這種方式存在一個比較明顯的缺點，那就是replay會涉及到資料的寫入，屬於IO操作，速度比較慢，因為讀取event和replay是在同個流程中，replay速度慢會導致讀取event的缺速度也比較慢，當主節點寫入的速度較快的時候，就會導致大量主備延遲，binary log會積壓大量沒有備份到Slave的情況，一旦Master節點出問題，Slave節點啟用的話會出現大量資料落後的不一致情況，且Slave節點也無法作為讀節點對外提供服務。

2. Relay Log引入

2002年，MySQL4.0.2引入了relay log,將Slave端讀取event和資料replay分開成了兩個流程，分別由IO執行緒和SQL執行緒兩個執行緒負責。其中，IO執行緒負責從Master節點讀取event，然後寫入本地的relay log，SQL執行緒從relay log中讀取event然後執行，將資料寫入本地庫。這樣子一來，即使SQL執行緒執行緩慢，也只是relay log擠壓，Master的binary log會透過IO執行緒儘可能快地同步到Slave節點，一旦Master出問題，切換到Slave，不會出現大量資料丟失不一致的情況，雖然還是有可能部分資料未及時透過IO執行緒寫入relay log,但是程度大大地減輕了。

3.半同步複製引入

2010年，為解決非同步複製Slave節點可能在Master宕機的情況下丟失binary log的問題，引入了半同步複製。在半同步複製的機制下，Master節點在應答客戶端提交的事務之前需要保證至少一個Slave接收到Master的event並寫realy log成功。

當然半同步還是存在一些問題：1、解決了Master宕機情況下relay log丟失的問題，但是仍然非強一致性，relay log可能還未被SQL執行緒寫入本地庫，此時的查詢仍然會有資料落後的可能。

2、主節點宕機，binary log還未傳給半同步節點，但是已經寫入本地binary log，此時切換到半同步節點執行，等待原主節點恢復以後，已經寫入的binary log會被繼續傳給半同步節點，可能造成主鍵衝突。

3、無法很好的支援故障自動切換的場景。

4.組複製的引入

2016年，MySQL5.7.17版本引入了Group Replication技術，這是一個“邏輯上”的同步的機制，在第一個節點收到一個事務時，會將事務廣播到叢集中的其他節點，等收到過半數節點同意以後，事務會在各個節點上獨立提交，也就是說各個節點只是在決定事務是否衝突、能否提交的階段是同步的，而事務的提交是非同步的。Group Replication技術是一項支援高可用、強資料一致性的方案，並且最重要的是將不再僅僅只是著眼於提供一個冗餘備份，而是從一個叢集的角度上來保障高可用和資料一致性，支援流控、故障自動切換等特性，運維比較簡單，在高可用和效能上實現了較好的平衡，整體優缺點總結如下：

優點：1、強一致性：基於分散式paxos變種協議實現組複製，保證資料強一致性；

2、高容錯性：自動故障和節點異常檢測機制，叢集過半數節點正常執行就可以保證叢集的可用性。

3、跨機房部署：過半數的節點的機制，適合跨機房的叢集容錯部署，同個機房內的節點網路間通訊的延遲較小。

4、高擴充套件性：節點的增加與移除會自動更新組成員資訊，新節點加入後，自動從其他節點同步增量資料，直到與其他節點資料一致，過程簡單，無需過多的人工干預。

5、多種模式：支援單主與多主模式

缺點：1、叢集要求比較穩定的網路環境，不適用於WAN場景。

2、多主情況下容易有衝突發生，造成業務交易成功率低。

3、資源消耗較多

其他的高可用方案基於非同步複製的主從方案最常見的高可用方案之一是採用非同步複製的方式，增加一個或者多個從節點，以實現主節點異常時可以快速切換，這種情況下經常會有binary log落後的情況，一般情況下也無法很好的實現自動切換，所以很多時候作為災備使用，並且業務上能夠接受一些資料丟失的情況。使用SAN共享儲存傳統的資料庫產品會使用SAN共享儲存在儲存資料，多個數據庫例項併發訪問共享儲存存取資料，應用透過虛擬IP訪問資料庫，當某個資料庫掛掉以後會由其他正常的例項接管虛擬IP繼續對外提供服務。這種方案有明顯的問題，一在於共享儲存的成本高，二在於共享儲存本身又稱為了單點。使用DRBD網路RAID方案DRBD是一個用軟體實現的、無共享的、伺服器之間映象塊裝置內容的儲存複製解決方案,實際使用並不多，主要原因在於DRBD本身速度會成為瓶頸，並且透過基於塊的儲存複製，只能作為災備，無法同時對外提供服務，存在比較大的資源浪費。使用NFS等網路檔案系統這種方案類似使用SAN共享儲存，但是效能會更差，網路檔案系統難以實現高吞吐，瓶頸非常明顯。使用分散式檔案系統使用分散式檔案系統存放資料是另外一種考慮的方向，不同的資料庫例項可以使用分散式檔案系統的資料，一致性和高可用交由底層分散式檔案系統處理，但是這種模式下也很難實現故障的切換，並且引入分散式檔案系統更加複雜。使用主主架構主主架構其實本質上也是非同步複製，相對於主從，主主架構的好處在於當其中一個節點故障時可以直接切換，免去了從節點切換為主節點的流程。但是，一般建議不要使用，因為可能存在主鍵衝突、從節點上誤操作同步到了主節點等情況，使用主從架構更加穩健。這種架構適用於對資料沒有強一致性要求，允許丟失少量資料的情況，當做災備或者提供更大的讀能力的場景。MariaDB Galera ClusterMariaDB是Mysql的一個分支，在業內也是被廣泛使用的，Galera Cluster是MariaDB提供的高可用的叢集方案，其在MySQL InnoDB儲存引擎基礎上打了wrep(虛擬全同步複製)patch，提供了強一致性、高可用的能力，Percona/MariaDB各自的發行版都支援了這個功能，目前支援XtraDB/InnoDB儲存引擎。Galera Cluster有以下優缺點：優點：1、同步複製(注意，這裡的同步仍然是指事務傳送到各個節點的過程，事務在各個節點的應用的過程仍然是非同步的，各個節點獨立的)2、真正的 multi-master，所有節點可以同時讀寫資料庫3、自動的節點成員控制，失效節點自動被清除4、新節點加入資料自動複製、支援並行複製5、事務不丟失，不存在主從不一致的情況下缺點：1、一般只支援三個節點，網路越慢，主節點越多，則越容易有效能的瓶頸，叢集擴充套件性受限。2、事務的提交需要等待叢集所有節點的確認回覆，無法支援跨機房部署的場景，因為跨機房的網路抖動延遲較大。3、多主情況下容易有衝突發生，造成業務交易成功率低。4、非MySQL官方，雖然社群也很優秀，但對於一些企業來說，會要求官方版本。MySQL NDB ClusterMySQL NDB Cluster是MySQL官方提供的叢集同步方案，是一個真正全同步的方案，整體架構如下：

叢集分為三種角色：

Management Node實現對叢集其他節點的管理，維護元資料資訊，例如資料節點記憶體大小、資料節點資料存放位置，SQL節點位置資訊等。

Data Node

存取資料，提供真正的資料查詢操作。

依賴叢集自身提供的同步機制，每個資料節點中的資料都是強一致的，事務的執行是同步的。

NDB Cluster的優缺點都比較明顯：

優點：1、資料能夠實現自動分片，具備較強的寫入擴充套件能力。

2、分散式、無共享架構，強一致性，具備較強的故障恢復能力。

3、基於記憶體，實時性較高，效能較好。

缺點：1、資料存放在記憶體，擴充套件能力受到記憶體大小的限制。

2、隨著節點數量的增加，網路通訊的代價會越來越高，效能會容易產生瓶頸。

3、引入了Management Node和SQL Node，叢集管理成本顯著增加。

故障切換的方式

隨著不同的高可用架構的出現，伴隨而來的是多種不同的故障切換的方式，不同的高可用架構需要配套合適的切換方式才能真正發揮故障容災的作用。

1、應用修改配置切換當某個資料庫節點出現故障以後，手工修改配置指向備庫節點，需要重啟服務，人工介入，效果極差。

2、DNS動態解析使用域名訪問資料庫，採用DNS解析的方式將具體連線的IP資訊返回給應用程式，編寫特定的檢查指令碼檢測主節點的可用性，當出現故障時動態修改DNS解析到備節點。這種方式的困難點在於DNS會有有效期內的快取，雖然可以調整快取時間，但操作起來還是不夠方便。

3、MMMMMM（Master-Master replication manager for MySQL），是一套支援雙主故障切換和雙主日常管理的指令碼程式，其原理是透過漂移虛擬IP的方式來處理單點故障，主要應用於MySQL雙主模式，注意，雙主只是意味著兩個節點都可以當作主節點使用，但是同一時刻只能有一個主節點對外提供服務。

其架構圖如下所示，每個節點上都安裝了mmm_agent，用於與mmm monitor通訊。

mmm_monitor：監控程序，負責所有的監控工作，決定和處理所有節點角色活動。

mmm_agent：執行在每個mysql伺服器上的代理程序，完成監控的探針工作和執行簡單的遠端服務設定命令。

mmm_monitor端會決定哪些VIP應該掛載哪個mysql節點上，當某一個節點出現異常，其能夠將VIP切到其他的節點。

值得注意的是，MMM模式使用起來並不方便，生產應用證明也不是很可靠，故應用不廣泛，專案已經很久沒有更新了。

4、MHAMHA（Master High Availability）是目前相對成熟的一套方案，用於進行故障切換和主從提升，能夠在0~30秒之內自動完成資料庫的故障切換操作，並且在進行故障切換的過程中，MHA能在最大程度上保證資料的一致性。

MHA支援修改全域性配置以及漂移虛擬IP，能夠實現故障切換對應用無感知，應用比較廣泛，被普遍生產應用證明了可靠性。

MHA架構引入了MHA Manage，可以獨立部署在一臺伺服器上MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master。整個故障轉移過程對應用程式完全透明,MHA模式適用於一主多從的場景。

5、自定義Proxy