1. 概述

我們?cè)诳紤]MySQL數(shù)據(jù)庫的高可用的架構(gòu)時(shí)，主要要考慮如下幾方面：

• 如果數(shù)據(jù)庫發(fā)生了宕機(jī)或者意外中斷等故障，能盡快恢復(fù)數(shù)據(jù)庫的可用性,，盡可能的減少停機(jī)時(shí)間,，保證業(yè)務(wù)不會(huì)因?yàn)閿?shù)據(jù)庫的故障而中斷,。

• 用作備份,、只讀副本等功能的非主節(jié)點(diǎn)的數(shù)據(jù)應(yīng)該和主節(jié)點(diǎn)的數(shù)據(jù)實(shí)時(shí)或者最終保持一致,。

• 當(dāng)業(yè)務(wù)發(fā)生數(shù)據(jù)庫切換時(shí)，切換前后的數(shù)據(jù)庫內(nèi)容應(yīng)當(dāng)一致,，不會(huì)因?yàn)閿?shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務(wù),。

關(guān)于對(duì)高可用的分級(jí)在這里我們不做詳細(xì)的討論，這里只討論常用高可用方案的優(yōu)缺點(diǎn)以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步復(fù)制

使用雙節(jié)點(diǎn)數(shù)據(jù)庫,，搭建單向或者雙向的半同步復(fù)制,。在5.7以后的版本中，由于lossless replication,、logical多線程復(fù)制等一些列新特性的引入，使得MySQL原生半同步復(fù)制更加可靠。

常見架構(gòu)如下：

通常會(huì)和proxy、keepalived等第三方軟件同時(shí)使用，即可以用來監(jiān)控?cái)?shù)據(jù)庫的健康，又可以執(zhí)行一系列管理命令,。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。

優(yōu)點(diǎn)：

1. 架構(gòu)比較簡單,，使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù),；

2. 雙節(jié)點(diǎn),，沒有主機(jī)宕機(jī)后的選主問題，直接切換即可；

3. 雙節(jié)點(diǎn),，需求資源少，部署簡單；

缺點(diǎn)：

1. 完全依賴于半同步復(fù)制,，如果半同步復(fù)制退化為異步復(fù)制,，數(shù)據(jù)一致性無法得到保證,；

2. 需要額外考慮haproxy、keepalived的高可用機(jī)制,。

2.2. 半同步復(fù)制優(yōu)化

半同步復(fù)制機(jī)制是可靠的,。如果半同步復(fù)制一直是生效的,，那么便可以認(rèn)為數(shù)據(jù)是一致的。但是由于網(wǎng)絡(luò)波動(dòng)等一些客觀原因,，導(dǎo)致半同步復(fù)制發(fā)生超時(shí)而切換為異步復(fù)制,，那么這時(shí)便不能保證數(shù)據(jù)的一致性,。所以盡可能的保證半同步復(fù)制，便可提高數(shù)據(jù)的一致性,。

該方案同樣使用雙節(jié)點(diǎn)架構(gòu),，但是在原有半同復(fù)制的基礎(chǔ)上做了功能上的優(yōu)化，使半同步復(fù)制的機(jī)制變得更加可靠,。

可參考的優(yōu)化方案如下：

2.2.1. 雙通道復(fù)制

半同步復(fù)制由于發(fā)生超時(shí)后,，復(fù)制斷開，當(dāng)再次建立起復(fù)制時(shí),，同時(shí)建立兩條通道,，其中一條半同步復(fù)制通道從當(dāng)前位置開始復(fù)制，保證從機(jī)知道當(dāng)前主機(jī)執(zhí)行的進(jìn)度,。另外一條異步復(fù)制通道開始追補(bǔ)從機(jī)落后的數(shù)據(jù),。當(dāng)異步復(fù)制通道追趕到半同步復(fù)制的起始位置時(shí)，恢復(fù)半同步復(fù)制,。

2.2.2. binlog文件服務(wù)器

搭建兩條半同步復(fù)制通道,，其中連接文件服務(wù)器的半同步通道正常情況下不啟用，當(dāng)主從的半同步復(fù)制發(fā)生網(wǎng)絡(luò)問題退化后,，啟動(dòng)與文件服務(wù)器的半同步復(fù)制通道,。當(dāng)主從半同步復(fù)制恢復(fù)后，關(guān)閉與文件服務(wù)器的半同步復(fù)制通道,。

優(yōu)點(diǎn)：

1. 雙節(jié)點(diǎn),，需求資源少，部署簡單,；

2. 架構(gòu)簡單,，沒有選主的問題,，直接切換即可;

3. 相比于原生復(fù)制，優(yōu)化后的半同步復(fù)制更能保證數(shù)據(jù)的一致性,。

缺點(diǎn)：

1. 需要修改內(nèi)核源碼或者使用mysql通信協(xié)議,。需要對(duì)源碼有一定的了解，并能做一定程度的二次開發(fā),。

2. 依舊依賴于半同步復(fù)制,，沒有從根本上解決數(shù)據(jù)一致性問題。

2.3. 高可用架構(gòu)優(yōu)化

將雙節(jié)點(diǎn)數(shù)據(jù)庫擴(kuò)展到多節(jié)點(diǎn)數(shù)據(jù)庫,，或者多節(jié)點(diǎn)數(shù)據(jù)庫集群,。可以根據(jù)自己的需要選擇一主兩從,、一主多從或者多主多從的集群,。

由于半同步復(fù)制，存在接收到一個(gè)從機(jī)的成功應(yīng)答即認(rèn)為半同步復(fù)制成功的特性,，所以多從半同步復(fù)制的可靠性要優(yōu)于單從半同步復(fù)制的可靠性,。并且多節(jié)點(diǎn)同時(shí)宕機(jī)的幾率也要小于單節(jié)點(diǎn)宕機(jī)的幾率，所以多節(jié)點(diǎn)架構(gòu)在一定程度上可以認(rèn)為高可用性是好于雙節(jié)點(diǎn)架構(gòu),。

但是由于數(shù)據(jù)庫數(shù)量較多,，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護(hù)性,?？梢赃x擇MMM、MHA或者各個(gè)版本的proxy等等,。常見方案如下：

2.3.1. MHA+多節(jié)點(diǎn)集群

MHA Manager會(huì)定時(shí)探測(cè)集群中的master節(jié)點(diǎn),，當(dāng)master出現(xiàn)故障時(shí)，它可以自動(dòng)將最新數(shù)據(jù)的slave提升為新的master,，然后將所有其他的slave重新指向新的master,，整個(gè)故障轉(zhuǎn)移過程對(duì)應(yīng)用程序完全透明。

MHA Node運(yùn)行在每臺(tái)MySQL服務(wù)器上,，主要作用是切換時(shí)處理二進(jìn)制日志,，確保切換盡量少丟數(shù)據(jù)。

MHA也可以擴(kuò)展到如下的多節(jié)點(diǎn)集群：

優(yōu)點(diǎn)：

1. 可以進(jìn)行故障的自動(dòng)檢測(cè)和轉(zhuǎn)移;

2. 可擴(kuò)展性較好,，可以根據(jù)需要擴(kuò)展MySQL的節(jié)點(diǎn)數(shù)量和結(jié)構(gòu);

3. 相比于雙節(jié)點(diǎn)的MySQL復(fù)制,，三節(jié)點(diǎn)/多節(jié)點(diǎn)的MySQL發(fā)生不可用的概率更低

缺點(diǎn)：

1. 至少需要三節(jié)點(diǎn)，相對(duì)于雙節(jié)點(diǎn)需要更多的資源;

2. 邏輯較為復(fù)雜,，發(fā)生故障后排查問題,，定位問題更加困難;

3. 數(shù)據(jù)一致性仍然靠原生半同步復(fù)制保證，仍然存在數(shù)據(jù)不一致的風(fēng)險(xiǎn);

4. 可能因?yàn)榫W(wǎng)絡(luò)分區(qū)發(fā)生腦裂現(xiàn)象;

2.3.2. zookeeper+proxy

Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性,，使用zookeeper可以有效的保證proxy的高可用性,，可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生,。

優(yōu)點(diǎn)：

1. 較好的保證了整個(gè)系統(tǒng)的高可用性，包括proxy,、MySQL;

2. 擴(kuò)展性較好,，可以擴(kuò)展為大規(guī)模集群;

缺點(diǎn)：

1. 數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復(fù)制;

2. 引入zk，整個(gè)系統(tǒng)的邏輯變得更加復(fù)雜;

2.4. 共享存儲(chǔ)

共享存儲(chǔ)實(shí)現(xiàn)了數(shù)據(jù)庫服務(wù)器和存儲(chǔ)設(shè)備的解耦,，不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復(fù)制功能,，而是通過磁盤數(shù)據(jù)同步的手段，來保證數(shù)據(jù)的一致性,。

2.4.1. SAN共享儲(chǔ)存

SAN的概念是允許存儲(chǔ)設(shè)備和處理器（服務(wù)器）之間建立直接的高速網(wǎng)絡(luò)（與LAN相比）連接,，通過這種連接實(shí)現(xiàn)數(shù)據(jù)的集中式存儲(chǔ)。常用架構(gòu)如下：

使用共享存儲(chǔ)時(shí),，MySQL服務(wù)器能夠正常掛載文件系統(tǒng)并操作,，如果主庫發(fā)生宕機(jī)，備庫可以掛載相同的文件系統(tǒng),，保證主庫和備庫使用相同的數(shù)據(jù),。

優(yōu)點(diǎn)：

1. 兩節(jié)點(diǎn)即可，部署簡單,，切換邏輯簡單,；

2. 很好的保證數(shù)據(jù)的強(qiáng)一致性；

3. 不會(huì)因?yàn)镸ySQL的邏輯錯(cuò)誤發(fā)生數(shù)據(jù)不一致的情況,；

缺點(diǎn)：

1. 需要考慮共享存儲(chǔ)的高可用,；

2. 價(jià)格昂貴；

2.4.2. DRBD磁盤復(fù)制

DRBD是一種基于軟件,、基于網(wǎng)絡(luò)的塊復(fù)制存儲(chǔ)解決方案,，主要用于對(duì)服務(wù)器之間的磁盤、分區(qū),、邏輯卷等進(jìn)行數(shù)據(jù)鏡像,，當(dāng)用戶將數(shù)據(jù)寫入本地磁盤時(shí)，還會(huì)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺(tái)主機(jī)的磁盤上,，這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時(shí)同步,。常用架構(gòu)如下：

當(dāng)本地主機(jī)出現(xiàn)問題，遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù),，可以繼續(xù)使用,，保證了數(shù)據(jù)的安全。

DRBD是linux內(nèi)核模塊實(shí)現(xiàn)的快級(jí)別的同步復(fù)制技術(shù),，可以與SAN達(dá)到相同的共享存儲(chǔ)效果,。

優(yōu)點(diǎn)：

1. 兩節(jié)點(diǎn)即可，部署簡單,，切換邏輯簡單,；

2. 相比于SAN儲(chǔ)存網(wǎng)絡(luò),，價(jià)格低廉；

3. 保證數(shù)據(jù)的強(qiáng)一致性,；

缺點(diǎn)：

1. 對(duì)io性能影響較大,；

2. 從庫不提供讀操作；

2.5. 分布式協(xié)議

分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題,。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案,，通過使用NDB存儲(chǔ)引擎實(shí)時(shí)備份冗余數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性,。

優(yōu)點(diǎn)：

1. 全部使用官方組件,，不依賴于第三方軟件；

2. 可以實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性,；

缺點(diǎn)：

1. 國內(nèi)使用的較少,；

2. 配置較復(fù)雜，需要使用NDB儲(chǔ)存引擎,，與MySQL常規(guī)引擎存在一定差異,；

3. 至少三節(jié)點(diǎn)；

2.5.2. Galera

基于Galera的MySQL高可用集群,， 是多主數(shù)據(jù)同步的MySQL集群解決方案,，使用簡單，沒有單點(diǎn)故障,，可用性高,。常見架構(gòu)如下：

優(yōu)點(diǎn)：

1. 多主寫入，無延遲復(fù)制,，能保證數(shù)據(jù)強(qiáng)一致性,；

2. 有成熟的社區(qū)，有互聯(lián)網(wǎng)公司在大規(guī)模的使用,；

3. 自動(dòng)故障轉(zhuǎn)移，自動(dòng)添加,、剔除節(jié)點(diǎn),；

缺點(diǎn)：

1. 需要為原生MySQL節(jié)點(diǎn)打wsrep補(bǔ)丁

2. 只支持innodb儲(chǔ)存引擎

3. 至少三節(jié)點(diǎn)；

2.5.3. POAXS

Paxos 算法解決的問題是一個(gè)分布式系統(tǒng)如何就某個(gè)值（決議）達(dá)成一致,。這個(gè)算法被認(rèn)為是同類算法中最有效的,。Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)的強(qiáng)一致性。常見架構(gòu)如下：

優(yōu)點(diǎn)：

1. 多主寫入,，無延遲復(fù)制,，能保證數(shù)據(jù)強(qiáng)一致性；

2. 有成熟理論基礎(chǔ),；

3. 自動(dòng)故障轉(zhuǎn)移,，自動(dòng)添加,、剔除節(jié)點(diǎn)；

缺點(diǎn)：

1. 只支持innodb儲(chǔ)存引擎

2. 至少三節(jié)點(diǎn),；

3. 總結(jié)

隨著人們對(duì)數(shù)據(jù)一致性的要求不斷的提高,，越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題，如MySQL自身的優(yōu)化,、MySQL集群架構(gòu)的優(yōu)化,、Paxos、Raft,、2PC算法的引入等等,。

而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受,，一系列成熟的產(chǎn)品如PhxSQL,、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用,。

隨著官方MySQL Group Replication的GA,，使用分布式協(xié)議來解決數(shù)據(jù)一致性問題已經(jīng)成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出,，MySQL高可用問題可以被更好的解決,。

參考文獻(xiàn)

[2015 OTN]彭立勛-DoubleBinlog方案.pdf

——————

其他閱讀推薦：

我如何使用 Django + Vue.js 快速構(gòu)建項(xiàng)目

一起學(xué) Node.js | 使用 Express + MongoDB 搭建多人博客

本文由『UCloud存儲(chǔ)研發(fā)團(tuán)隊(duì)』提供。

關(guān)于作者：

王松磊,，現(xiàn)任職于UCloud,，從事MySQL數(shù)據(jù)庫內(nèi)核研發(fā)工作。主要負(fù)責(zé)UCloud云數(shù)據(jù)庫udb的內(nèi)核故障排查工作以及數(shù)據(jù)庫新特性的研發(fā)工作,。

———以下是活動(dòng)的分割線———

歡迎加入 UCloud開源作者交流群,，遇見更多有意思的項(xiàng)目和作者。

添加UCloud運(yùn)營小妹個(gè)人微信號(hào)：Surdur,，備注：開源作者,，我們將拉你進(jìn)群！

另,，運(yùn)營小妹也陪聊很專業(yè)哦：）

「UCloud機(jī)構(gòu)號(hào)」將獨(dú)家分享云計(jì)算領(lǐng)域的技術(shù)洞見,、行業(yè)資訊以及一切你想知道的相關(guān)訊息。歡迎提問&求關(guān)注 o(*////▽////*)q~

以上,。