導讀 | 資料庫是所有應用系統的核心,故保證資料庫穩定、有效率、安全地運作是所有企業日常工作的重中之重。資料庫系統一旦出現問題無法提供服務,就有可能導致整個系統都無法繼續運作。所以,一個成功的資料庫架構在高可用設計方面也是需要充分考慮的。以下就為大家介紹如何建構一個高可用的MySQL資料庫系統。 |
資料庫是所有應用系統的核心,故確保資料庫穩定、有效率、安全地運作是所有企業日常工作的重中之重。資料庫系統一旦出現問題無法提供服務,就有可能導致整個系統都無法繼續運作。所以,一個成功的資料庫架構在高可用設計方面也是需要充分考慮的。以下就為大家介紹如何建構一個高可用的MySQL資料庫系統。
做過DBA或是維運的同學都應該知道,任何設備或服務,存在單點就會帶來巨大風險,因為這台實體機一旦宕機或服務模組crash,若在短時間內無法找到替換的設備,勢必會影響整個應用系統。因而如何保證不出現單點就是我們的重要工作,使用MySQL高可用方案可以很好地解決這個問題,一般有以下幾種:
一、利用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中的時間戳記資訊進行對照,來找到準確的複製起始點,從而避免造成數據的丟失。
二、利用MYSQL CLUSTER實現整體的高可用就目前而言,利用MYSQL CLUSTER實現整體的高可用(即NDB CLUSTER)的方案在國內的公司並沒有很普及。 NDB CLUSTER節點其實就是一個多節點的MySQL伺服器,但不包含數據,所以任何機器只要安裝了就可以使用。當叢集中某一個sql節點crash之後,因為節點不存具體的數據,所以資料不會遺失。如圖六:
圖六
在目前MySQL實現高可用的衍生產品中,知名度的和普及度比較高的是GALERA CLUSTER和PERCONA XTRDB CLUSTER(PXC)。相關的內容本文暫不展開講述,有興趣的同學可以查閱相關資料進一步了解。這兩種集群的實作方式都是類似的,如圖七、圖八:
圖七
#
圖八
在前面各種高可用設計方案的介紹中讀者們可能已經發現,不管是哪一種方案,都存在自己獨特的優勢,但也都或多或少存在一些限制。這一節將針對上面的幾個主要方案做一個利弊分析,以供大家選擇過程中參考。
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的動力。
以上是對MySQL架構進行簡要分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!