淺析開源數(shù)據(jù)庫MySQL架構(gòu)

數(shù)據(jù)庫是所有應(yīng)用系統(tǒng)的核心，故保證數(shù)據(jù)庫穩(wěn)定、高效、安全地運(yùn)行是所有企業(yè)日常工作的重中之重。數(shù)據(jù)庫系統(tǒng)一旦出現(xiàn)問題無法提供服務(wù)，有可能導(dǎo)致整個(gè)系統(tǒng)都無法繼續(xù)工作。所以，一個(gè)成功的數(shù)據(jù)庫架構(gòu)在高可用設(shè)計(jì)方面也是需要充分考慮的。下面就為大家介紹一下如何構(gòu)建一個(gè)高可用的MySQL數(shù)據(jù)庫系統(tǒng)。

做過DBA或者是運(yùn)維的同學(xué)都應(yīng)該知道，任何設(shè)備或服務(wù)，存在單點(diǎn)就會(huì)帶來巨大風(fēng)險(xiǎn)，因?yàn)檫@臺(tái)物理機(jī)一旦宕機(jī)或服務(wù)模塊crash，若在短時(shí)間內(nèi)無法找到替換的設(shè)備，勢必會(huì)影響整個(gè)應(yīng)用系統(tǒng)。因而如何保證不出現(xiàn)單點(diǎn)就是我們的重要工作，使用MySQL高可用方案可以很好地解決這個(gè)問題，一般有以下幾種：

一、利用MySQL自身的Replication來實(shí)現(xiàn)高可用

MySQL自帶的Replication就是我們常說的主從復(fù)制（AB復(fù)制），通過對(duì)主服務(wù)器做一個(gè)從機(jī)，在主服務(wù)器宕機(jī)的情況下快速地將業(yè)務(wù)切換到從機(jī)上，保證應(yīng)用的正常使用。利用AB復(fù)制做高可用方案也分為幾種不同的架構(gòu)：

1、常規(guī)的MASTER---SLAVE解決方案

普通的MASTER---SLAVE是目前國內(nèi)外大多數(shù)中小型公司最常用的一種架構(gòu)方案，主要的好處就是簡單、使用設(shè)備較少（成本較低）、維護(hù)方便。這種架構(gòu)能解決單點(diǎn)的問題，而且還能在很大程度上解決系統(tǒng)的性能問題。在一個(gè)MASTER后面可以帶上一個(gè)或者多個(gè)的SLAVE（主從級(jí)聯(lián)復(fù)制），不過這種架構(gòu)要求一個(gè)MASTER必須能夠滿足系統(tǒng)所有的寫請(qǐng)求，不然就需要做水平拆分分擔(dān)讀的壓力。

圖一

圖二

圖一到圖二展示的是：解決單點(diǎn)問題和利用讀寫分離達(dá)到提高性能的過程。

2、DUAL MASTER與級(jí)聯(lián)復(fù)制結(jié)合

雙主多從是在上面的方案中衍生而來的一種更加合理的方案。這個(gè)方案的好處是：當(dāng)兩個(gè)主服務(wù)器中任何一個(gè)掛掉時(shí)，整個(gè)架構(gòu)都不用做大的調(diào)整。

圖三

圖四

圖五

這個(gè)過程如上圖所示。但圖五這種情況比較特殊，即MASTER-B宕機(jī)的話怎么辦呢？首先可以確定的是我們的所有Write請(qǐng)求都不會(huì)受到任何影響，而且所有的Read請(qǐng)求也都能夠正常訪問；但所有Slave的復(fù)制都會(huì)中斷，Slave上面的數(shù)據(jù)會(huì)開始出現(xiàn)滯后的現(xiàn)象。這時(shí)候我們需要做的就是將所有的Slave進(jìn)行CHANGE MASTER TO操作，改為從Master A進(jìn)行復(fù)制。由于所有Slave的復(fù)制都不可能超前最初的數(shù)據(jù)源，所以可以根據(jù)Slave上面的Relay Log中的時(shí)間戳信息與Master A中的時(shí)間戳信息進(jìn)行對(duì)照，來找到準(zhǔn)確的復(fù)制起始點(diǎn)，從而避免造成數(shù)據(jù)的丟失。

二、利用MYSQL CLUSTER實(shí)現(xiàn)整體的高可用

就目前而言，利用MYSQL CLUSTER實(shí)現(xiàn)整體的高可用（即NDB CLUSTER）的方案在國內(nèi)的公司并沒有很普及。NDB CLUSTER節(jié)點(diǎn)實(shí)際上就是一個(gè)多節(jié)點(diǎn)的MySQL服務(wù)器，但是并不包含數(shù)據(jù)，所以任何機(jī)器只要安裝了就可以使用。當(dāng)集群中某一個(gè)sql節(jié)點(diǎn)crash之后，因?yàn)楣?jié)點(diǎn)不存具體的數(shù)據(jù)，所以數(shù)據(jù)不會(huì)丟失。如圖六：

圖六

三、通過MySQL的衍生產(chǎn)品實(shí)現(xiàn)高可用

在目前MySQL實(shí)現(xiàn)高可用的衍生產(chǎn)品中，知名度的和普及度比較高的是GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）。相關(guān)的內(nèi)容本文暫不展開講述，感興趣的同學(xué)可以查閱相關(guān)資料進(jìn)一步了解。這兩種集群的實(shí)現(xiàn)方式都是類似的，如圖七、圖八：

圖七

圖八

四、各種高可用方案的利弊比較

在前面各種高可用設(shè)計(jì)方案的介紹中讀者們可能已經(jīng)發(fā)現(xiàn)，不管是哪一種方案，都存在自己獨(dú)特的優(yōu)勢，但也都或多或少存在一些限制。這一節(jié)將針對(duì)上面的幾種主要方案做一個(gè)利弊分析，以供大家選擇過程中參考。

1、MySQL Replication

優(yōu)勢：部署簡單，實(shí)施方便，維護(hù)也不復(fù)雜，是MySQL天生就支持的功能。且主備機(jī)之間切換方便，通過第三方軟件或者自行編寫的腳本即可自動(dòng)完成主備切換。

劣勢：如果Master主機(jī)硬件故障且無法恢復(fù)，則可能造成部分未傳送到Slave端的數(shù)據(jù)丟失。

2、MySQL Cluster （NDB）

優(yōu)勢：可用性非常高，性能非常好。每一份數(shù)據(jù)至少在不同主機(jī)上面存在一份拷貝，且冗余數(shù)據(jù)拷貝實(shí)時(shí)同步。

劣勢：維護(hù)較為復(fù)雜，產(chǎn)品較新，存在部分bug，目前還不一定適用于比較核心的線上系統(tǒng)。

3、GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）

優(yōu)勢：可靠性非常高，所有節(jié)點(diǎn)可以同時(shí)讀寫每一份數(shù)據(jù)，至少在不同主機(jī)上面存在一份拷貝，且冗余數(shù)據(jù)拷貝實(shí)時(shí)同步。

劣勢：隨著集群的規(guī)模擴(kuò)大，性能會(huì)越來越差。

4、 不得不提的DRBD磁盤網(wǎng)絡(luò)鏡像方案

從架構(gòu)上來說，它有點(diǎn)類似Replication，只是它是通過第三方的軟件實(shí)現(xiàn)數(shù)據(jù)同步的過程，可靠性比Replication更高，但是也犧牲了性能。

優(yōu)勢：軟件功能強(qiáng)大，數(shù)據(jù)在底層塊設(shè)備級(jí)別跨物理主機(jī)鏡像，且可根據(jù)性能和可靠性要求配置不同級(jí)別的同步。IO操作保持順序，可滿足數(shù)據(jù)庫對(duì)數(shù)據(jù)一致性的苛刻要求。

劣勢：非分布式文件系統(tǒng)環(huán)境無法支持鏡像數(shù)據(jù)同時(shí)可見，即性能和可靠性兩者相互矛盾，無法適用于對(duì)二者要求都比較苛刻的環(huán)境。維護(hù)成本高于MySQL Replication。

說完了各種常用架構(gòu)的優(yōu)缺點(diǎn)后，剩下的就是如何選擇合適的架構(gòu)在現(xiàn)實(shí)的生產(chǎn)環(huán)境中使用的問題。在這方面每個(gè)人都有自己的想法和經(jīng)驗(yàn)，具體哪個(gè)方案是最優(yōu)的就見仁見智了。在日常的工作中架構(gòu)的完善并不是一蹴而就，而是一個(gè)不斷演變優(yōu)化完善的過程。

個(gè)推在數(shù)據(jù)庫方面也經(jīng)歷了從單點(diǎn)到主從再到主從+高可用的過程，同時(shí)也經(jīng)歷了從單一的MySQL+redis到MySQL+redis+es，最后到現(xiàn)在MySQL+redis+es+codis等等的演變。每一次的演變都是為了解決生產(chǎn)環(huán)境下的實(shí)際問題和痛點(diǎn)。單從MySQL來說任何一個(gè)架構(gòu)都無法解決所有的問題（痛點(diǎn)），都需要根據(jù)實(shí)際的情況選擇一個(gè)合適架構(gòu)。MySQL集群實(shí)現(xiàn)的方案非常靈活多變，對(duì)于MySQL工作者來說如何選擇一個(gè)合適的架構(gòu)也是一種挑戰(zhàn)，同時(shí)也是我們不斷鉆研和學(xué)習(xí)MySQL的動(dòng)力。