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

1. 何謂Galera Cluster

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

圖1 Galera Cluster架構(gòu)

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

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

2. 為什么需要Galera Cluster

MySQL在互聯(lián)網(wǎng)時(shí)代,可謂是深受世人矚目的.給社會(huì)創(chuàng)造了無限價(jià)值,隨之而來的是,在MySQL基礎(chǔ)之上,產(chǎn)生了形形色色的使用方法、架構(gòu)及周邊產(chǎn)品.本文所關(guān)注的是架構(gòu),在這方面,已經(jīng)有很多成熟的被人熟知的產(chǎn)品,比如MHA、MMM等傳統(tǒng)組織架構(gòu),而這些架構(gòu)是每個(gè)需要數(shù)據(jù)庫高可用服務(wù)方案的入門必備選型.

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

幸運(yùn)的是,MySQL的福音來了,Galera Cluster就是我們需要的——從此變得完美的架構(gòu).

相比傳統(tǒng)的主從復(fù)制架構(gòu),Galera Cluster解決的最核心問題是,在三個(gè)實(shí)例(節(jié)點(diǎn))之間,它們的關(guān)系是對等的,multi-master架構(gòu)的,在多節(jié)點(diǎn)同時(shí)寫入的時(shí)候,能夠保證整個(gè)集群數(shù)據(jù)的一致性,完整性與正確性.

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

3. Galera Cluster如何解決問題

3.1 Galera的引入

現(xiàn)在已經(jīng)知道,Galera Cluster是MySQL封裝了具有高一致性,支持多點(diǎn)寫入的同步通信模塊Galera而做的,它是建立在MySQL同步基礎(chǔ)之上的,使用Galera Cluster時(shí),應(yīng)用程序可以直接讀、寫某個(gè)節(jié)點(diǎn)的最新數(shù)據(jù),并且可以在不影響應(yīng)用程序讀寫的情況下,下線某個(gè)節(jié)點(diǎn),因?yàn)橹С侄帱c(diǎn)寫入,使得Failover變得非常簡單.

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

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

這種方式的復(fù)制,也被稱為是虛擬同步復(fù)制,實(shí)際上是一種邏輯上的同步,因?yàn)槊總€(gè)節(jié)點(diǎn)的寫入和提交操作還是獨(dú)立的,更準(zhǔn)確的說是異步的,Galera Cluster是建立在一種樂觀復(fù)制的基礎(chǔ)上的,假設(shè)集群中的每個(gè)節(jié)點(diǎn)都是同步的,那么加上在寫入時(shí),都會(huì)做驗(yàn)證,那么理論上是不會(huì)出現(xiàn)不一致的,當(dāng)然也不能這么樂觀,如果出現(xiàn)不一致了,比如主庫(相對)插入成功,而從庫則出現(xiàn)主鍵沖突,那說明此時(shí)數(shù)據(jù)庫已經(jīng)不一致,這種時(shí)候Galera Cluster采取的方式是將出現(xiàn)不一致數(shù)據(jù)的節(jié)點(diǎn)踢出集群,其實(shí)是自己shutdown了.

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

1. 多主架構(gòu)：真正的多點(diǎn)讀寫的集群,在任何時(shí)候讀寫數(shù)據(jù),都是最新的.
2. 同步復(fù)制：集群不同節(jié)點(diǎn)之間數(shù)據(jù)同步,沒有延遲,在數(shù)據(jù)庫掛掉之后,數(shù)據(jù)不會(huì)丟失.
3. 并發(fā)復(fù)制：從節(jié)點(diǎn)在APPLY數(shù)據(jù)時(shí),支持并行執(zhí)行,有更好的性能表現(xiàn).
4. 故障切換：在出現(xiàn)數(shù)據(jù)庫故障時(shí),因?yàn)橹С侄帱c(diǎn)寫入,切的非常容易.
5. 熱插拔：在服務(wù)期間,如果數(shù)據(jù)庫掛了,只要監(jiān)控程序發(fā)現(xiàn)的夠快,不可服務(wù)時(shí)間就會(huì)非常少.在節(jié)點(diǎn)故障期間,節(jié)點(diǎn)本身對集群的影響非常小.
6. 自動(dòng)節(jié)點(diǎn)克隆：在新增節(jié)點(diǎn),或者停機(jī)維護(hù)時(shí),增量數(shù)據(jù)或者基礎(chǔ)數(shù)據(jù)不需要人工手動(dòng)備份提供,Galera Cluster會(huì)自動(dòng)拉取在線節(jié)點(diǎn)數(shù)據(jù),最終集群會(huì)變?yōu)橐恢?
7. 對應(yīng)用透明：集群的維護(hù),對應(yīng)用程序是透明的,幾乎感覺不到. 以上幾點(diǎn),足以說明Galera Cluster是一個(gè)既穩(wěn)健,又在數(shù)據(jù)一致性、完整性及高性能方面有出色表現(xiàn)的高可用解決方案.

不過在運(yùn)維過程中,有些技術(shù)特點(diǎn)還是需要注意的,這樣才能做到知此知彼,百戰(zhàn)百勝,因?yàn)楝F(xiàn)在MySQL主從結(jié)構(gòu)的集群已經(jīng)都是被大家所熟知的了,而Galera Cluster是一個(gè)新的技術(shù),是一個(gè)在不斷成熟的技術(shù),所以很多想了解這個(gè)技術(shù)的同學(xué),能夠得到的資料很少,除了官方的手冊之外,基本沒有一些講得深入的,用來傳道授業(yè)解惑的運(yùn)維資料,這無疑為很多同學(xué)設(shè)置了不低的門檻,最終有很多人因?yàn)橐恍┨匦?導(dǎo)致最終放棄了Galera Cluster的選擇.

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

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

      

      圖2 galera原理圖

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

a. 本地執(zhí)行：這個(gè)階段,是事務(wù)執(zhí)行的最初階段,可以說,這個(gè)階段的執(zhí)行過程,與單點(diǎn)MySQL執(zhí)行沒什么區(qū)別,并發(fā)控制當(dāng)然就是數(shù)據(jù)庫的并發(fā)控制了,而不是Galera Cluster的并發(fā)控制了.

b. 寫集發(fā)送：在執(zhí)行完之后,就到了提交階段,提交之前首先將產(chǎn)生的寫集廣播出去,而為了保證全局?jǐn)?shù)據(jù)的一致性,在寫集發(fā)送時(shí),需要串行,這個(gè)就屬于Galera Cluster并發(fā)控制的一部分了.

c. 寫集驗(yàn)證：這個(gè)階段,就是我們通常說的Galera Cluster的驗(yàn)證了,驗(yàn)證是將當(dāng)前的事務(wù),與本地寫集驗(yàn)證緩存集來做驗(yàn)證,通過比對寫集中被影響的數(shù)據(jù)庫KEYS,來發(fā)現(xiàn)有沒有相同的,來確定是不是可以驗(yàn)證通過,那么這個(gè)過程,也是串行的.

d. 寫集提交：這個(gè)階段,是一個(gè)事務(wù)執(zhí)行時(shí)的最后一個(gè)階段了,驗(yàn)證完成之后,就可以進(jìn)入提交階段了,因?yàn)樾r(shí)已經(jīng)執(zhí)行完了的,而提交操作的并發(fā)控制,是可以通過參數(shù)來控制其行為的,即參數(shù)repl.commit_order,如果設(shè)置為3,表示提交就是串行的了,而這也是本人所推薦的(默認(rèn)值)的一種設(shè)置,因?yàn)檫@樣的結(jié)果是,集群中不同節(jié)點(diǎn)產(chǎn)生的Binlog是完全一樣的,運(yùn)維中帶來了不少好處和方便.其它值的解釋,以后有機(jī)會(huì)再做講解.

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

3.2 流量控制

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

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

假設(shè)從節(jié)點(diǎn)真的堆積了,那么Galera會(huì)讓它一直堆積下去么?這樣延遲會(huì)越來越嚴(yán)重,這樣Galera Cluster就變成一個(gè)主從架構(gòu)的集群了,已經(jīng)失去了強(qiáng)一致狀態(tài)的屬性了,那么很明顯,Galera是不會(huì)讓這種事情發(fā)生的,那么此時(shí),就說回到開頭提到的參數(shù)了,gcs.fc_limit,這個(gè)參數(shù)是在MySQL參數(shù)wsrep_provider_options中來配置的,這個(gè)參數(shù)是Galera的一個(gè)參數(shù)集合,有關(guān)于Flow Control的,還包括gcs.fc_factor,這兩個(gè)參數(shù)的意義是,當(dāng)從節(jié)點(diǎn)堆積的事務(wù)數(shù)量超過gcs.fc_limit的值時(shí),從節(jié)點(diǎn)就發(fā)起一個(gè)Flow Control,而當(dāng)從節(jié)點(diǎn)堆積的事務(wù)數(shù)小于gcs.fc_limit * gcs.fc_factor時(shí),發(fā)起Flow Control的從節(jié)點(diǎn)再發(fā)起一個(gè)解除的消息,讓整個(gè)集群再恢復(fù).

但我們一般所關(guān)心的,就是如何解決,下面有幾個(gè)一般所采用的方法：

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

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

3.3 有很多坑?

有很多同學(xué),在使用過Galera Cluster之后,發(fā)現(xiàn)很多問題,最大的比如DDL的執(zhí)行,大事務(wù)等,從而導(dǎo)致服務(wù)的不友好,這也是導(dǎo)致很多人放棄的原因.

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

4. 適用場景

現(xiàn)在對Galera Cluster已經(jīng)有了足夠了解,但這樣的“完美”架構(gòu),在什么場景下才可以使用呢?或者說,哪種場景又不適合使用這樣的架構(gòu)呢?針對它的缺點(diǎn),及優(yōu)點(diǎn),我們可以揚(yáng)其長,避其短.可以通過下面幾個(gè)方面,來了解其適用場景.

1. 數(shù)據(jù)強(qiáng)一致性：因?yàn)镚alera Cluster,可以保證數(shù)據(jù)強(qiáng)一致性的,所以它更適合應(yīng)用于對數(shù)據(jù)一致性和完整性要求特別高的場景,比如交易,正是因?yàn)檫@個(gè)特性,我們?nèi)ツ膬壕W(wǎng)才會(huì)成為使用Galera Cluster的第一大戶.
2. 多點(diǎn)寫入：這里要強(qiáng)調(diào)多點(diǎn)寫入的意思,不是要支持以多點(diǎn)寫入的方式提供服務(wù),更重要的是,因?yàn)橛辛硕帱c(diǎn)寫入,才會(huì)使得在DBA正常維護(hù)數(shù)據(jù)庫集群的時(shí)候,才會(huì)不影響到業(yè)務(wù),做到真正的無感知,因?yàn)橹灰侵鲝膹?fù)制,就不能出現(xiàn)多點(diǎn)寫入,從而導(dǎo)致了在切換時(shí),必然要將老節(jié)點(diǎn)的連接斷掉,然后齊刷刷的切到新節(jié)點(diǎn),這是沒辦法避免的,而支持了多點(diǎn)寫入,在切換時(shí)刻允許有短暫的多點(diǎn)寫入,從而不會(huì)影響老的連接,只需要將新連接都路由到新節(jié)點(diǎn)即可.這個(gè)特性,對于交易型的業(yè)務(wù)而言,也是非常渴求的.
3. 性能：Galera Cluster,能支持到強(qiáng)一致性,毫無疑問,也是以犧牲性能為代價(jià),爭取了數(shù)據(jù)一致性,但要問：”性能犧牲了,會(huì)不會(huì)導(dǎo)致性能太差,這樣的架構(gòu)根本不能滿足需求呢?”這里只想說的是,這是一個(gè)權(quán)衡過程,有多少業(yè)務(wù),QPS大到Galera Cluster不能滿足的?我想是不多的(當(dāng)然也是有的,可以自行做一些測試),在追求非常高的極致性能情況下,也許單個(gè)的Galera Cluster集群是不能滿足需求的,但畢竟是少數(shù)了,所以夠用就好,Galera Cluster必然是MySQL方案中的佼佼者.

5. 總結(jié)

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

原文來自微信公眾號：Qunar技術(shù)沙龍

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2740.html