《Galera Cluster：一種新型的高一致性MySQL集群架構》要點：
本文介紹了Galera Cluster：一種新型的高一致性MySQL集群架構，希望對您有用。如果有疑問，可以聯系我們。

1. 何謂Galera Cluster

何謂Galera Cluster?就是集成了Galera插件的MySQL集群,是一種新型的,數據不共享的,高度冗余的高可用方案,目前Galera Cluster有兩個版本,分別是Percona Xtradb Cluster及MariaDB Cluster,都是基于Galera的,所以這里都統稱為Galera Cluster了,因為Galera本身是具有多主特性的,所以Galera Cluster也就是multi-master的集群架構,如圖1所示：

圖1 Galera Cluster架構

圖1中有三個實例,組成了一個集群,而這三個節點與普通的主從架構不同,它們都可以作為主節點,三個節點是對等的,這種一般稱為multi-master架構,當有客戶端要寫入或者讀取數據時,隨便連接哪個實例都是一樣的,讀到的數據是相同的,寫入某一個節點之后,集群自己會將新數據同步到其它節點上面,這種架構不共享任何數據,是一種高冗余架構.

一般的使用方法是,在這個集群上面,再搭建一個中間層,這個中間層的功能包括建立連接、管理連接池,負責使三個實例的負載基本平衡,負責在客戶端與實例的連接斷開之后重連,也可以負責讀寫分離(在機器性能不同的情況下可以做這樣的優化)等等,使用這個中間層之后,由于這三個實例的架構在客戶端方面是透明的,客戶端只需要指定這個集群的數據源地址,連接到中間層即可,中間層會負責客戶端與服務器實例連接的傳遞工作,由于這個架構支持多點寫入,所以完全避免了主從復制經常出現的數據不一致的問題,從而可以做到主從讀寫切換的高度優雅,在不影響用戶的情況下,離線維護等工作,MySQL的高可用,從此開始,非常完美.

2. 為什么需要Galera Cluster

MySQL在互聯網時代,可謂是深受世人矚目的.給社會創造了無限價值,隨之而來的是,在MySQL基礎之上,產生了形形色色的使用方法、架構及周邊產品.本文所關注的是架構,在這方面,已經有很多成熟的被人熟知的產品,比如MHA、MMM等傳統組織架構,而這些架構是每個需要數據庫高可用服務方案的入門必備選型.

不幸的是,傳統架構的使用,一直被人們所詬病,因為MySQL的主從模式,天生的不能完全保證數據一致,很多大公司會花很大人力物力去解決這個問題,而效果卻一般,可以說,只能是通過犧牲性能,來獲得數據一致性,但也只是在降低數據不一致性的可能性而已.所以現在就急需一種新型架構,從根本上解決這樣的問題,天生的擺脫掉主從復制模式這樣的“美中不足”之處了.

幸運的是,MySQL的福音來了,Galera Cluster就是我們需要的——從此變得完美的架構.

相比傳統的主從復制架構,Galera Cluster解決的最核心問題是,在三個實例(節點)之間,它們的關系是對等的,multi-master架構的,在多節點同時寫入的時候,能夠保證整個集群數據的一致性,完整性與正確性.

在傳統MySQL的使用過程中,也不難實現一種multi-master架構,但是一般需要上層應用來配合,比如先要約定每個表必須要有自增列,并且如果是2個節點的情況下,一個節點只能寫偶數的值,而另一個節點只能寫奇數的值,同時2個節點之間互相做復制,因為2個節點寫入的東西不同,所以復制不會沖突,在這種約定之下,可以基本實現多master的架構,也可以保證數據的完整性與一致性.但這種方式使用起來還是有限制,同時還會出現復制延遲,并且不具有擴展性,不是真正意義上的集群.

3. Galera Cluster如何解決問題

3.1 Galera的引入

現在已經知道,Galera Cluster是MySQL封裝了具有高一致性,支持多點寫入的同步通信模塊Galera而做的,它是建立在MySQL同步基礎之上的,使用Galera Cluster時,應用程序可以直接讀、寫某個節點的最新數據,并且可以在不影響應用程序讀寫的情況下,下線某個節點,因為支持多點寫入,使得Failover變得非常簡單.

所有的Galera Cluster,都是對Galera所提供的接口API做了封裝,這些API為上層提供了豐富的狀態信息及回調函數,通過這些回調函數,做到了真正的多主集群,多點寫入及同步復制,這些API被稱作是Write-Set Replication API,簡稱為wsrep API.

通過這些API,Galera Cluster提供了基于驗證的復制,是一種樂觀的同步復制機制,一個將要被復制的事務(稱為寫集),不僅包括被修改的數據庫行,還包括了這個事務產生的所有Binlog,每一個節點在復制事務時,都會拿這些寫集與正在APPLY隊列的寫集做比對,如果沒有沖突的話,這個事務就可以繼續提交,或者是APPLY,這個時候,這個事務就被認為是提交了,然后在數據庫層面,還需要繼續做事務上的提交操作.

這種方式的復制,也被稱為是虛擬同步復制,實際上是一種邏輯上的同步,因為每個節點的寫入和提交操作還是獨立的,更準確的說是異步的,Galera Cluster是建立在一種樂觀復制的基礎上的,假設集群中的每個節點都是同步的,那么加上在寫入時,都會做驗證,那么理論上是不會出現不一致的,當然也不能這么樂觀,如果出現不一致了,比如主庫(相對)插入成功,而從庫則出現主鍵沖突,那說明此時數據庫已經不一致,這種時候Galera Cluster采取的方式是將出現不一致數據的節點踢出集群,其實是自己shutdown了.

而通過使用Galera,它在里面通過判斷鍵值的沖突方式實現了真正意義上的multi-master,Galera Cluster在MySQL生態中,在高可用方面實現了非常重要的提升,目前Galera Cluster具備的功能包括如下幾個方面：

1. 多主架構：真正的多點讀寫的集群,在任何時候讀寫數據,都是最新的.
2. 同步復制：集群不同節點之間數據同步,沒有延遲,在數據庫掛掉之后,數據不會丟失.
3. 并發復制：從節點在APPLY數據時,支持并行執行,有更好的性能表現.
4. 故障切換：在出現數據庫故障時,因為支持多點寫入,切的非常容易.
5. 熱插拔：在服務期間,如果數據庫掛了,只要監控程序發現的夠快,不可服務時間就會非常少.在節點故障期間,節點本身對集群的影響非常小.
6. 自動節點克隆：在新增節點,或者停機維護時,增量數據或者基礎數據不需要人工手動備份提供,Galera Cluster會自動拉取在線節點數據,最終集群會變為一致.
7. 對應用透明：集群的維護,對應用程序是透明的,幾乎感覺不到. 以上幾點,足以說明Galera Cluster是一個既穩健,又在數據一致性、完整性及高性能方面有出色表現的高可用解決方案.

不過在運維過程中,有些技術特點還是需要注意的,這樣才能做到知此知彼,百戰百勝,因為現在MySQL主從結構的集群已經都是被大家所熟知的了,而Galera Cluster是一個新的技術,是一個在不斷成熟的技術,所以很多想了解這個技術的同學,能夠得到的資料很少,除了官方的手冊之外,基本沒有一些講得深入的,用來傳道授業解惑的運維資料,這無疑為很多同學設置了不低的門檻,最終有很多人因為一些特性,導致最終放棄了Galera Cluster的選擇.

目前熟知的一些特性,或者在運維中需要注意的一些特性,有以下幾個方面：

1. 1. Galera Cluster寫集內容：Galera Cluster復制的方式,還是基于Binlog的,這個問題,也是一直被人糾結的,因為目前Percona Xtradb Cluster所實現的版本中,在將Binlog關掉之后,還是可以使用的,這誤導了很多人,其實關掉之后,只是不落地了,表象上看上去是沒有使用Binlog了,實際上在內部還是悄悄的打開了的.除此之外,寫集中還包括了事務影響的所有行的主鍵,所有主鍵組成了寫集的KEY,而Binlog組成了寫集的DATA,這樣一個KEY-DATA就是寫集.KEY和DATA分別具有不同的作用的,KEY是用來驗證的,驗證與其它事務沒有沖突,而DATA是用來在驗證通過之后,做APPLY的.
   2. Galera Cluster的并發控制：現在都已經知道,Galera Cluster可以實現集群中,數據的高度一致性,并且在每個節點上,生成的Binlog順序都是一樣的,這與Galera內部,實現的并發控制機制是分不開的.所有的上層到下層的同步、復制、執行、提交都是通過并發控制機制來管理的.這樣才能保證上層的邏輯性,下層數據的完整性等.

      

      圖2 galera原理圖

   3. 圖2是從官方手冊中截取的,從圖中可以大概看出,從事務執行開始,到本地執行,再到寫集發送,再到寫集驗證,再到寫集提交的整個過程,以及從節點(相對)收到寫集之后,所做的寫集驗證、寫集APPLY及寫集提交操作,通過對比這個圖,可以很好的理解每一個階段的意義及性能等,下面就每一個階段以及其并發控制行為做一個簡單的介紹：

a. 本地執行：這個階段,是事務執行的最初階段,可以說,這個階段的執行過程,與單點MySQL執行沒什么區別,并發控制當然就是數據庫的并發控制了,而不是Galera Cluster的并發控制了.

b. 寫集發送：在執行完之后,就到了提交階段,提交之前首先將產生的寫集廣播出去,而為了保證全局數據的一致性,在寫集發送時,需要串行,這個就屬于Galera Cluster并發控制的一部分了.

c. 寫集驗證：這個階段,就是我們通常說的Galera Cluster的驗證了,驗證是將當前的事務,與本地寫集驗證緩存集來做驗證,通過比對寫集中被影響的數據庫KEYS,來發現有沒有相同的,來確定是不是可以驗證通過,那么這個過程,也是串行的.

d. 寫集提交：這個階段,是一個事務執行時的最后一個階段了,驗證完成之后,就可以進入提交階段了,因為些時已經執行完了的,而提交操作的并發控制,是可以通過參數來控制其行為的,即參數repl.commit_order,如果設置為3,表示提交就是串行的了,而這也是本人所推薦的(默認值)的一種設置,因為這樣的結果是,集群中不同節點產生的Binlog是完全一樣的,運維中帶來了不少好處和方便.其它值的解釋,以后有機會再做講解.

e. 寫集APPLY：這個階段,與上面的幾個在流程上不太一樣,這個階段是從節點做的事情,從節點只包括兩個階段,即寫集驗證和寫集APPLY,寫集APPLY的并發控制,是與參數wsrep_slave_threads有關系的,本身在驗證之后,確定了相互的依賴關系之后,如果確定沒有關系的,就可以并行了,而并行度,就是參數wsrep_slave_threads的事情了.wsrep_slave_threads可以參照參數wsrep_cert_deps_distance來設置.

3.2 流量控制

在PXC中,有一個參數叫fc_limit,它的全名其實是叫flow control limit,顧名思義,是流量控制大小限制的意思,它的作用是什么呢?

如果一套集群中,某個節點,或者某幾個節點的硬件資源比較差,或者由于節點壓力大,導致復制效率低下,等等各種原因,導致的結果是,從節點APPLY時,非常慢,也就是說,主庫在一秒鐘之內做的操作,從庫有可能會用2秒才能完成,那么這種情況下,就會導致從節點執行任務的堆積,接收隊列的堆積.

假設從節點真的堆積了,那么Galera會讓它一直堆積下去么?這樣延遲會越來越嚴重,這樣Galera Cluster就變成一個主從架構的集群了,已經失去了強一致狀態的屬性了,那么很明顯,Galera是不會讓這種事情發生的,那么此時,就說回到開頭提到的參數了,gcs.fc_limit,這個參數是在MySQL參數wsrep_provider_options中來配置的,這個參數是Galera的一個參數集合,有關于Flow Control的,還包括gcs.fc_factor,這兩個參數的意義是,當從節點堆積的事務數量超過gcs.fc_limit的值時,從節點就發起一個Flow Control,而當從節點堆積的事務數小于gcs.fc_limit * gcs.fc_factor時,發起Flow Control的從節點再發起一個解除的消息,讓整個集群再恢復.

但我們一般所關心的,就是如何解決,下面有幾個一般所采用的方法：

1. 發送FC消息的節點,硬件有可能出現問題了,比如IO寫不進去,很慢,CPU異常高等
2. 發送FC消息的節點,本身數據庫壓力太高,比如當前節點承載太多的讀,導致機器Load高,IO壓力大等等.
3. 發送FC消息的節點,硬件壓力都沒有太大問題,但做得比較慢,一般原因是主庫并發高,但從節點的并發跟不上主庫,那么此時可能需要觀察這兩個節點的并發度大小,可以參考狀態參數wsrep_cert_deps_distance的值,來調整從節點的wsrep_slave_threads,此時應該是可以解決或者緩解的,這個問題可以這樣去理解,假設集群每個節點的硬件資源都是相當的,那么主庫可以執行完,從庫為什么做不過來?那么一般思路就是像處理主從復制的延遲問題一樣.
4. 檢查存不存在沒有主鍵的表,因為Galera的復制是行模式的,所以如果存在這樣的表時,主節點是通過語句來修改的,比如一個更新語句,更新了全表,而從節點收到之后,就會針對每一行的Binlog做一次全表掃描,這樣導致這個事務在從節點執行,比在主節點執行慢十倍,或者百倍,從而導致從節點堆積進而產生FC.

可以看出,其實這些方法,都是用來解決主從復制延遲的方法,沒什么兩樣,在了解Flow Control的情況下,解決它并不是難事兒.

3.3 有很多坑?

有很多同學,在使用過Galera Cluster之后,發現很多問題,最大的比如DDL的執行,大事務等,從而導致服務的不友好,這也是導致很多人放棄的原因.

1. DDL執行卡死傳說：使用過的同學可能知道,在Galera Cluster中執行一個大的改表操作,會導致整個集群在一段時間內,是完全寫入不了任何事務的,都卡死在那里,這個情況確實很嚴重,導致線上完全不可服務了,原因還是并發控制,因為提交操作設置為串行的,DDL執行是一個提交的過程,那么串行執行改表,當然執行多久,就卡多久,直到改表執行完,其它事務也就可以繼續操作了,這個問題現在沒辦法解決,但我們長期使用下來發現,小表可以這樣直接操作,大一點或者更大的,都是通過osc(pt-online-schema-change)來做,這樣就很好的避免了這個問題.
2. 擋我者死：由于Galera Cluster在執行DDL時,是Total Ordered Isolation(wsrep_OSU_method=TOI)的,所以必須要保證每個節點都是同時執行的,當然對于不是DDL的,也是Total Order的,因為每一個事務都具有同一個GTID值,DDL也不例外,而DDL涉及到的是表鎖,MDL鎖(Meta Data Lock),只要在執行過程中,遇到了MDL鎖的沖突,所有情況下,都是DDL優先,將所有的使用到這個對象的事務,統統殺死,不管是讀事務,還是寫事務,被殺的事務都會報出死鎖的異常,所以這也是一個Galera Cluster中,關于DDL的聞名遐邇的坑.不過這個現在確實沒有辦法解決,也沒辦法避免,不過這個的影響還算可以接受,先可以忍忍.
3. 不死之身：繼上面的“擋我者死”,如果集群真的被一個DDL卡死了,導致整個集群都動不了了,所有的寫請求都Hang住了,那么可能會有人想一個妙招,說趕緊殺死,直接在每個節點上面輸入kill connection_id,等等類似的操作,那么此時,很不愿意看到的信息報了出來：You are not owner of thread connection_id.此時可能有些同學要哭了,不過這種情況下,確實沒有什么好的解決方法(其實這個時候,一個故障已經發生了,一年的KPI也許已經沒有了,就看敢不敢下狠手了),要不就等DDL執行完成(所有這個數據庫上面的業務都處于不可服務狀態),要不就將數據庫直接Kill掉,快速重啟,趕緊恢復一個節點提交線上服務,然后再考慮集群其它節點的數據增量的同步等,這個坑非常大,也是在Galera Cluster中,最大的一個坑,需要非常小心,避免出現這樣的問題.

4. 適用場景

現在對Galera Cluster已經有了足夠了解,但這樣的“完美”架構,在什么場景下才可以使用呢?或者說,哪種場景又不適合使用這樣的架構呢?針對它的缺點,及優點,我們可以揚其長,避其短.可以通過下面幾個方面,來了解其適用場景.

1. 數據強一致性：因為Galera Cluster,可以保證數據強一致性的,所以它更適合應用于對數據一致性和完整性要求特別高的場景,比如交易,正是因為這個特性,我們去哪兒網才會成為使用Galera Cluster的第一大戶.
2. 多點寫入：這里要強調多點寫入的意思,不是要支持以多點寫入的方式提供服務,更重要的是,因為有了多點寫入,才會使得在DBA正常維護數據庫集群的時候,才會不影響到業務,做到真正的無感知,因為只要是主從復制,就不能出現多點寫入,從而導致了在切換時,必然要將老節點的連接斷掉,然后齊刷刷的切到新節點,這是沒辦法避免的,而支持了多點寫入,在切換時刻允許有短暫的多點寫入,從而不會影響老的連接,只需要將新連接都路由到新節點即可.這個特性,對于交易型的業務而言,也是非常渴求的.
3. 性能：Galera Cluster,能支持到強一致性,毫無疑問,也是以犧牲性能為代價,爭取了數據一致性,但要問：”性能犧牲了,會不會導致性能太差,這樣的架構根本不能滿足需求呢?”這里只想說的是,這是一個權衡過程,有多少業務,QPS大到Galera Cluster不能滿足的?我想是不多的(當然也是有的,可以自行做一些測試),在追求非常高的極致性能情況下,也許單個的Galera Cluster集群是不能滿足需求的,但畢竟是少數了,所以夠用就好,Galera Cluster必然是MySQL方案中的佼佼者.

5. 總結

綜上所述,Galera Cluster是一個完全可依賴的,MySQL數據一致性的絕殺利器,使用中完全不需要擔心數據延遲,數據不一致的問題,DBA從此就從繁復的數據修復、解決復制延遲、維護時擔心影響業務的問題中徹底解脫了.可以說Galera Cluster是DBA及業務系統的福音,也是MySQL發展的大趨勢,我希望它會越來越好,也希望也有越來越多的人使用它,共同維護這個美好的大環境.

原文來自微信公眾號：Qunar技術沙龍

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/2740.html