淺析開源數據庫MySQL架構

數據庫是全部應用系統的核心，故保證數據庫穩定、高效、安全地運行是全部企業平常工做的重中之重。數據庫系統一旦出現問題沒法提供服務，有可能致使整個系統都沒法繼續工做。因此，一個成功的數據庫架構在高可用設計方面也是須要充分考慮的。下面就爲你們介紹一下如何構建一個高可用的MySQL數據庫系統。

作過DBA或者是運維的同窗都應該知道，任何設備或服務，存在單點就會帶來巨大風險，由於這臺物理機一旦宕機或服務模塊crash，若在短期內沒法找到替換的設備，勢必會影響整個應用系統。於是如何保證不出現單點就是咱們的重要工做，使用MySQL高可用方案能夠很好地解決這個問題，通常有如下幾種：

1、利用MySQL自身的Replication來實現高可用

MySQL自帶的Replication就是咱們常說的主從複製（AB複製），經過對主服務器作一個從機，在主服務器宕機的狀況下快速地將業務切換到從機上，保證應用的正常使用。利用AB複製作高可用方案也分爲幾種不一樣的架構：

1、常規的MASTER---SLAVE解決方案

普通的MASTER---SLAVE是目前國內外大多數中小型公司最經常使用的一種架構方案，主要的好處就是簡單、使用設備較少（成本較低）、維護方便。這種架構能解決單點的問題，並且還能在很大程度上解決系統的性能問題。在一個MASTER後面能夠帶上一個或者多個的SLAVE（主從級聯複製），不過這種架構要求一個MASTER必須可以知足系統全部的寫請求，否則就須要作水平拆分分擔讀的壓力。

圖一

 

圖二

圖一到圖二展現的是：解決單點問題和利用讀寫分離達到提升性能的過程。

2、DUAL MASTER與級聯複製結合

雙主多從是在上面的方案中衍生而來的一種更加合理的方案。這個方案的好處是：當兩個主服務器中任何一個掛掉時，整個架構都不用作大的調整。

 

圖三

 

圖四

 

圖五

這個過程如上圖所示。但圖五這種狀況比較特殊，即MASTER-B宕機的話怎麼辦呢？首先能夠肯定的是咱們的全部Write請求都不會受到任何影響，並且全部的Read請求也都可以正常訪問；但全部Slave的複製都會中斷，Slave上面的數據會開始出現滯後的現象。這時候咱們須要作的就是將全部的Slave進行CHANGE MASTER TO操做，改成從Master A進行復制。因爲全部Slave的複製都不可能超前最初的數據源，因此能夠根據Slave上面的Relay Log中的時間戳信息與Master A中的時間戳信息進行對照，來找到準確的複製起始點，從而避免形成數據的丟失。

2、利用MYSQL CLUSTER實現總體的高可用

就目前而言，利用MYSQL CLUSTER實現總體的高可用（即NDB CLUSTER）的方案在國內的公司並無很普及。NDB CLUSTER節點實際上就是一個多節點的MySQL服務器，可是並不包含數據，因此任何機器只要安裝了就可使用。當集羣中某一個sql節點crash以後，由於節點不存具體的數據，因此數據不會丟失。如圖六：

 

圖六

3、經過MySQL的衍生產品實現高可用

在目前MySQL實現高可用的衍生產品中，知名度的和普及度比較高的是GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）。相關的內容本文暫不展開講述，感興趣的同窗能夠查閱相關資料進一步瞭解。這兩種集羣的實現方式都是相似的，如圖7、圖八：

 

圖七

 

圖八

4、各類高可用方案的利弊比較

在前面各類高可用設計方案的介紹中讀者們可能已經發現，不論是哪種方案，都存在本身獨特的優點，但也都或多或少存在一些限制。這一節將針對上面的幾種主要方案作一個利弊分析，以供你們選擇過程當中參考。

1、MySQL Replication

優點：部署簡單，實施方便，維護也不復雜，是MySQL天生就支持的功能。且主備機之間切換方便，經過第三方軟件或者自行編寫的腳本便可自動完成主備切換。

劣勢：若是Master主機硬件故障且沒法恢復，則可能形成部分未傳送到Slave端的數據丟失。

2、MySQL Cluster （NDB）

優點：可用性很是高，性能很是好。每一份數據至少在不一樣主機上面存在一份拷貝，且冗餘數據拷貝實時同步。

劣勢：維護較爲複雜，產品較新，存在部分bug，目前還不必定適用於比較核心的線上系統。

3、GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）

優點：可靠性很是高，全部節點能夠同時讀寫每一份數據，至少在不一樣主機上面存在一份拷貝，且冗餘數據拷貝實時同步。

劣勢：隨着集羣的規模擴大，性能會愈來愈差。

4、 不得不提的DRBD磁盤網絡鏡像方案

從架構上來講，它有點相似Replication，只是它是經過第三方的軟件實現數據同步的過程，可靠性比Replication更高，可是也犧牲了性能。

優點：軟件功能強大，數據在底層塊設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不一樣級別的同步。IO操做保持順序，可知足數據庫對數據一致性的苛刻要求。

劣勢：非分佈式文件系統環境沒法支持鏡像數據同時可見，即性能和可靠性二者相互矛盾，沒法適用於對兩者要求都比較苛刻的環境。維護成本高於MySQL Replication。

說完了各類經常使用架構的優缺點後，剩下的就是如何選擇合適的架構在現實的生產環境中使用的問題。在這方面每一個人都有本身的想法和經驗，具體哪一個方案是最優的就見仁見智了。在平常的工做中架構的完善並非一蹴而就，而是一個不斷演變優化完善的過程。

個推在數據庫方面也經歷了從單點到主從再到主從+高可用的過程，同時也經歷了從單一的MySQL+redis到MySQL+redis+es，最後到如今MySQL+redis+es+codis等等的演變。每一次的演變都是爲了解決生產環境下的實際問題和痛點。單從MySQL來講任何一個架構都沒法解決全部的問題（痛點），都須要根據實際的狀況選擇一個合適架構。MySQL集羣實現的方案很是靈活多變，對於MySQL工做者來講如何選擇一個合適的架構也是一種挑戰，同時也是咱們不斷鑽研和學習MySQL的動力。