1.什么是Galera星團(tuán)

什么是Galera Cluster？與Galera插件集成的MySQL集群是一種新的、數(shù)據(jù)共享的、高度冗余和高度可用的解決方案。目前Galera Cluster有兩個(gè)版本，Percona Xtradb Cluster和MariaDB Cluster，都是基于Galera的，所以這里都叫Galera Cluster。Galera Cluster是多主機(jī)的集群架構(gòu)，因?yàn)镚alera本身具有多主機(jī)的特性，如圖1所示:

圖1 Galera集群架構(gòu)

圖1中有三個(gè)實(shí)例，它們形成了一個(gè)集群。這三個(gè)節(jié)點(diǎn)不同于常見的主從架構(gòu)，都可以作為主節(jié)點(diǎn)，三個(gè)節(jié)點(diǎn)是相等的。這種架構(gòu)一般稱為多主架構(gòu)。當(dāng)客戶端想要寫入或讀取數(shù)據(jù)時(shí)，連接任何實(shí)例都是一樣的，讀取的數(shù)據(jù)也是一樣的。寫入某個(gè)節(jié)點(diǎn)后，集群會(huì)將新數(shù)據(jù)同步到其他節(jié)點(diǎn)。該架構(gòu)不共享任何數(shù)據(jù)。

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

2.為什么需要Galera Cluster

在互聯(lián)網(wǎng)時(shí)代，MySQL已經(jīng)引起了全世界的關(guān)注。它為社會(huì)創(chuàng)造了無限的價(jià)值，與之相伴，在MySQL的基礎(chǔ)上出現(xiàn)了各種使用方法、架構(gòu)和外圍產(chǎn)品。本文主要研究建筑。在這方面，有許多成熟和知名的產(chǎn)品，如MHA、MMM和其他傳統(tǒng)的組織架構(gòu)，這些架構(gòu)是每個(gè)需要數(shù)據(jù)庫高可用性的服務(wù)方案的必要入口選擇。

遺憾的是，傳統(tǒng)架構(gòu)的使用一直受到人們的批評(píng)，因?yàn)镸ySQL的主從模式不能完全保證數(shù)據(jù)一致性，很多大公司會(huì)花費(fèi)大量的人力物力來解決這個(gè)問題，但效果一般?？梢哉f，數(shù)據(jù)一致性只能通過犧牲性能來獲得，但這只是降低了數(shù)據(jù)不一致的可能性。因此，迫切需要一種新的架構(gòu)來從根本上解決這個(gè)問題，擺脫主從復(fù)制模式的“美中不足”。

好在MySQL的福音來了，Galera Cluster就是我們需要的——從此完美的架構(gòu)。

與傳統(tǒng)的主從復(fù)制架構(gòu)相比，Galera Cluster解決的核心問題是三個(gè)實(shí)例之間的關(guān)系相等，多主架構(gòu)可以保證多個(gè)節(jié)點(diǎn)同時(shí)寫入時(shí)整個(gè)集群數(shù)據(jù)的一致性、完整性和正確性。

在傳統(tǒng)的MySQL使用中，實(shí)現(xiàn)多主架構(gòu)并不難，但一般需要上層應(yīng)用的配合。比如首先約定每個(gè)表必須有自增列，在兩個(gè)節(jié)點(diǎn)的情況下，一個(gè)節(jié)點(diǎn)只能寫偶數(shù)的值，另一個(gè)節(jié)點(diǎn)只能寫奇數(shù)的值。同時(shí)，兩個(gè)節(jié)點(diǎn)互相復(fù)制。因?yàn)閮蓚€(gè)節(jié)點(diǎn)寫的東西不一樣，所以復(fù)制不會(huì)沖突。在這個(gè)協(xié)議下，基本可以實(shí)現(xiàn)。但是這種方法使用受限，會(huì)有復(fù)制延遲，而且不可伸縮，所以不是真正的集群。

3.Galera Cluster如何解決問題3.1 Galera簡介

現(xiàn)在我們知道Galera Cluster是用MySQL封裝Galera做的，Galera是一個(gè)同步通信模塊，一致性高，支持多點(diǎn)寫入。是基于MySQL同步的。使用Galera Cluster時(shí)，應(yīng)用程序可以直接讀寫一個(gè)節(jié)點(diǎn)的最新數(shù)據(jù)，也可以注銷一個(gè)節(jié)點(diǎn)而不影響應(yīng)用程序的讀寫。由于支持多點(diǎn)寫入，故障轉(zhuǎn)移變得非常簡單。

所有Galera Cluster都封裝了Galera提供的接口API。這些API為上層提供了豐富的狀態(tài)信息和回調(diào)函數(shù)。通過這些回調(diào)函數(shù)，實(shí)現(xiàn)了真正的多主集群、多點(diǎn)寫入和同步復(fù)制。這些應(yīng)用編程接口被稱為寫集復(fù)制接口，簡稱wsrep接口。

通過這些API，Galera Cluster提供了基于驗(yàn)證的復(fù)制，這是一種樂觀的同步復(fù)制機(jī)制。要復(fù)制的事務(wù)不僅包括已修改的數(shù)據(jù)庫行，還包括由該事務(wù)生成的所有Binlog。當(dāng)每個(gè)節(jié)點(diǎn)復(fù)制一個(gè)事務(wù)時(shí)，它會(huì)將這些寫集與APPLY隊(duì)列中的寫集進(jìn)行比較。如果沒有沖突，此事務(wù)可以繼續(xù)提交或應(yīng)用。此時(shí)，該事務(wù)被視為已提交，然后在數(shù)據(jù)庫級(jí)別，需要繼續(xù)提交事務(wù)。

這種方式的復(fù)制也稱為虛擬同步復(fù)制，實(shí)際上是一種邏輯同步，因?yàn)槊總€(gè)節(jié)點(diǎn)的寫和提交操作是獨(dú)立的，更準(zhǔn)確地說是異步的。Galera Cluster基于樂觀復(fù)制。假設(shè)集群中每個(gè)節(jié)點(diǎn)都是同步的，寫的時(shí)候會(huì)做驗(yàn)證，理論上不會(huì)有不一致，當(dāng)然也不會(huì)那么樂觀。如果有不一致，比如主庫插入成功，而從庫有主鍵沖突，說明此時(shí)數(shù)據(jù)庫已經(jīng)不一致。在這種情況下，Galera Cluster采取的方法是從集群中踢出數(shù)據(jù)不一致的節(jié)點(diǎn)，但實(shí)際上是關(guān)閉自己。

利用Galera，通過判斷鍵值沖突實(shí)現(xiàn)真正的多主。Galera Cluster在MySQL生態(tài)中實(shí)現(xiàn)了非常重要的高可用性提升。目前，Galera集群具有以下功能:

多主機(jī)架構(gòu):一個(gè)真正的多點(diǎn)集群，隨時(shí)讀寫數(shù)據(jù)，是最新的。

同步復(fù)制:集群中不同節(jié)點(diǎn)之間的數(shù)據(jù)同步?jīng)]有延遲，數(shù)據(jù)庫掛起后不會(huì)丟失數(shù)據(jù)。

并發(fā)復(fù)制:從節(jié)點(diǎn)應(yīng)用數(shù)據(jù)時(shí)，支持并行執(zhí)行，性能更好。

故障轉(zhuǎn)移:在數(shù)據(jù)庫故障的情況下，切換非常容易，因?yàn)樗С侄帱c(diǎn)寫入。

熱插拔:在服務(wù)期間，如果數(shù)據(jù)庫掛起，只要監(jiān)控器足夠快地找到它，無法使用的時(shí)間就會(huì)非常小。在節(jié)點(diǎn)故障期間，節(jié)點(diǎn)本身對(duì)集群的影響很小。

自動(dòng)克隆節(jié)點(diǎn):添加新節(jié)點(diǎn)或停止維護(hù)時(shí)，不需要手動(dòng)備份增量數(shù)據(jù)或基礎(chǔ)數(shù)據(jù)，Galera Cluster會(huì)自動(dòng)將節(jié)點(diǎn)數(shù)據(jù)拉在線上，最終使集群變得一致。

對(duì)應(yīng)用透明:集群維護(hù)對(duì)應(yīng)用透明，幾乎察覺不到。以上幾點(diǎn)足以說明Galera Cluster是一個(gè)高度可用的解決方案，它是健壯的，并且在數(shù)據(jù)一致性、完整性和高性能方面具有突出的性能。

但是在運(yùn)維過程中，還是需要注意一些技術(shù)特性，這樣才能互相了解，贏得每一場戰(zhàn)斗，因?yàn)镸ySQL主從集群現(xiàn)在大家都很熟悉，而Galera Cluster是一種新技術(shù)，也是一種日趨成熟的技術(shù)，所以很多想了解這項(xiàng)技術(shù)的同學(xué)能得到的信息很少，除了官方的手冊(cè)，基本上沒有深入的信息。用來傳道、授業(yè)、解惑的運(yùn)維教材無疑給很多學(xué)生設(shè)置了很高的門檻，很多人最終因?yàn)橐恍┨攸c(diǎn)而放棄了Galera Cluster的選擇。

目前一些眾所周知的特性，或者一些在操作和維護(hù)中需要注意的特性，有以下幾個(gè)方面:

Galera Cluster寫內(nèi)容:Galera Cluster復(fù)制模式還是基于Binlog的，一直很糾結(jié)，因?yàn)樵赑ercona Xtradb Cluster實(shí)現(xiàn)的當(dāng)前版本中，Binlog關(guān)閉后還可以使用，誤導(dǎo)了很多人。事實(shí)上，它關(guān)閉后，就是不著陸。表面上不使用Binlog，其實(shí)里面是悄悄打開的。此外，寫入集還包括受事務(wù)影響的所有行的主鍵。所有主鍵構(gòu)成寫集的鍵，而Binlog構(gòu)成寫集的數(shù)據(jù)，因此鍵數(shù)據(jù)是寫集。密鑰和數(shù)據(jù)分別具有不同的功能。KEY用于驗(yàn)證，驗(yàn)證與其他事務(wù)不沖突，DATA用于驗(yàn)證通過后應(yīng)用。

Galera Cluster的并發(fā)控制:眾所周知Galera Cluster可以在集群中實(shí)現(xiàn)高度的數(shù)據(jù)一致性，生成的Binlog序列在每個(gè)節(jié)點(diǎn)上是相同的，這與Galera中實(shí)現(xiàn)的并發(fā)控制機(jī)制密不可分。從上層到下層的所有同步、復(fù)制、執(zhí)行和提交都由并發(fā)控制機(jī)制管理。這樣才能保證上層的邏輯和下層數(shù)據(jù)的完整性。

圖2 galera原理圖

圖2摘自官方手冊(cè)。從圖中大致可以看出，從事務(wù)執(zhí)行到本地執(zhí)行，再到寫集合發(fā)送，再到寫集合驗(yàn)證，再到寫集合提交的整個(gè)過程，以及從節(jié)點(diǎn)接收到寫集合后執(zhí)行的寫集合驗(yàn)證、寫集合APPLY、寫集合提交操作。通過對(duì)比這個(gè)數(shù)字，我們可以很好的了解各個(gè)階段的意義和表現(xiàn)等。

A.本地執(zhí)行:這個(gè)階段是事務(wù)執(zhí)行的初始階段。可以說這一階段的執(zhí)行過程和單點(diǎn)MySQL執(zhí)行沒有什么不同。并發(fā)控制當(dāng)然是數(shù)據(jù)庫的并發(fā)控制，而不是Galera Cluster的并發(fā)控制。

B.寫集發(fā)送:執(zhí)行完畢后，會(huì)進(jìn)入提交階段。提交之前，將首先廣播生成的寫入集。為了保證全局?jǐn)?shù)據(jù)的一致性，需要串行發(fā)送寫集合，這是Galera Cluster并發(fā)控制的一部分。

C.writeset驗(yàn)證:這個(gè)階段就是我們通常所說的Galera Cluster驗(yàn)證。驗(yàn)證是用本地writeset驗(yàn)證緩存集驗(yàn)證當(dāng)前事務(wù)，并找出writeset中受影響的數(shù)據(jù)庫中是否有任何相同的KEYS，以確定驗(yàn)證是否可以通過。那么這個(gè)過程也是連續(xù)的。

D.寫集合提交:這個(gè)階段是事務(wù)執(zhí)行的最后階段。驗(yàn)證完成后，就可以進(jìn)入提交階段了，因?yàn)橐呀?jīng)執(zhí)行了一段時(shí)間，提交操作的并發(fā)控制可以通過參數(shù)控制其行為，也就是參數(shù)repl。提交訂單。如果設(shè)置為3，則表示提交是串行的，這也是我推薦的之一，其他值的解釋將在后面說明。

E.write set APPLY:就流程而言，這個(gè)階段與上面的階段非常不同。這個(gè)階段由從節(jié)點(diǎn)完成，它只包括兩個(gè)階段，即寫集驗(yàn)證和寫集應(yīng)用，寫集應(yīng)用的并發(fā)控制與參數(shù)wsrep_slave_threads有關(guān)。驗(yàn)證后，確定相互依賴關(guān)系后，如果確定沒有關(guān)系，則可以并行。Wsrep_slave_threads可以參考參數(shù)wsrep_cert_deps_distance進(jìn)行設(shè)置。

3.2 流量控制

在PXC中，有一個(gè)參數(shù)叫做fc_limit。它的全稱實(shí)際上叫做流量控制極限。顧名思義，它意味著流量控制大小限制。它的功能是什么？

如果集群中某個(gè)節(jié)點(diǎn)或者幾個(gè)節(jié)點(diǎn)的硬件資源很差，或者由于節(jié)點(diǎn)的壓力導(dǎo)致復(fù)制效率低下等。，結(jié)果是從節(jié)點(diǎn)的APPLY非常慢，也就是說主庫在一秒鐘內(nèi)完成的操作可能會(huì)在兩秒鐘內(nèi)被從庫完成。在這種情況下，它將導(dǎo)致從屬節(jié)點(diǎn)執(zhí)行的任務(wù)的累積和接收隊(duì)列的累積

假設(shè)從節(jié)點(diǎn)真的堆積，Galera會(huì)一直堆積嗎？這樣延遲會(huì)越來越嚴(yán)重，Galera Cluster會(huì)變成主從集群，失去了強(qiáng)一致狀態(tài)的屬性。所以很明顯，Galera是不會(huì)讓這種事情發(fā)生的。這時(shí)，讓我們回到開頭提到的參數(shù)，gcs.fc_limit。此參數(shù)在MySQL參數(shù)wsrep_provider_options中配置。該參數(shù)是Galera的一個(gè)參數(shù)集，與Flow Control相關(guān)，包含gcs.fc_factor，這兩個(gè)參數(shù)的含義是當(dāng)節(jié)點(diǎn)累計(jì)的事務(wù)數(shù)超過gcs.fc_limit的值時(shí)，從節(jié)點(diǎn)發(fā)起一個(gè)Flow Control，當(dāng)從節(jié)點(diǎn)累計(jì)的事務(wù)數(shù)小于gcs.fc_limit * gcs.fc_factor時(shí)，發(fā)起Flow Control的從節(jié)點(diǎn)發(fā)起一個(gè)release消息，恢復(fù)整個(gè)集群。

但我們普遍關(guān)心的是如何解決。以下是一些常用的方法:

發(fā)送FC消息的節(jié)點(diǎn)可能存在硬件問題，比如IO寫不進(jìn)去，速度慢，CPU異常高

發(fā)送FC消息的節(jié)點(diǎn)數(shù)據(jù)庫壓力過大，比如當(dāng)前節(jié)點(diǎn)攜帶讀取太多，導(dǎo)致機(jī)器負(fù)載大，IO壓力大。

發(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。這個(gè)時(shí)候應(yīng)該解決或者緩解。這個(gè)問題可以這樣理解。假設(shè)集群中每個(gè)節(jié)點(diǎn)的硬件資源是等價(jià)的，那么就可以執(zhí)行主庫。為什么奴隸庫做不到？總體思路是處理主從復(fù)制的延遲問題。

檢查是否存在沒有主鍵的表，因?yàn)镚alera的復(fù)制是行模式，所以如果存在這樣的表，主節(jié)點(diǎn)會(huì)通過一條語句對(duì)其進(jìn)行修改，比如update語句，更新整個(gè)表。從從節(jié)點(diǎn)收到后，會(huì)掃描整個(gè)表尋找每一行的Binlog，導(dǎo)致事務(wù)在從節(jié)點(diǎn)執(zhí)行，比主節(jié)點(diǎn)慢十倍甚至百倍，從而導(dǎo)致從節(jié)點(diǎn)堆積生成FC。

可見，其實(shí)這些方法都是用來解決主從復(fù)制延遲的，沒什么區(qū)別，理解流控也不難解決。

3.3坑多？

很多同學(xué)，在使用Galera Cluster后，發(fā)現(xiàn)了很多問題，比如DDL執(zhí)行，大生意等。，導(dǎo)致服務(wù)不友好，也導(dǎo)致很多人放棄。

DDL執(zhí)行卡頓傳說:用過的同學(xué)可能知道，在Galera Cluster中執(zhí)行一個(gè)大表修改操作，會(huì)導(dǎo)致整個(gè)集群在那里卡頓一段時(shí)間，根本不寫任何事務(wù)。這種情況真的很嚴(yán)重，導(dǎo)致完全在線無法使用。原因是并發(fā)控制，因?yàn)樘峤徊僮髟O(shè)置為串行，DDL執(zhí)行是提交過程，所以表修改的串行執(zhí)行。當(dāng)然，只要執(zhí)行了，其他事務(wù)就可以繼續(xù)操作，直到執(zhí)行表修改。這個(gè)問題現(xiàn)在還不能解決，但是經(jīng)過長期使用，我們發(fā)現(xiàn)小表可以直接這樣操作，甚至更大的都是通過osc來做，很好的避免了這個(gè)問題。

誰擋我的道誰就死:因?yàn)镚alera Cluster在執(zhí)行DDL時(shí)總是有序隔離，所以需要保證每個(gè)節(jié)點(diǎn)都是同時(shí)執(zhí)行的，當(dāng)然對(duì)于那些Total Order而不是DDL總是有序的，因?yàn)槊總€(gè)事務(wù)都有相同的GTID值，DDL也不例外。而DDL涉及到表鎖和MDL鎖。只要執(zhí)行過程中有MDL鎖沖突，DDL在所有情況下都優(yōu)先，殺死所有使用這個(gè)對(duì)象的事務(wù)。無論是讀事務(wù)還是寫事務(wù)，被殺的事務(wù)都會(huì)報(bào)告死鎖異常，所以這也是Galera Cluster中關(guān)于DDL的一個(gè)著名坑。但是，現(xiàn)在真的沒有辦法解決這個(gè)問題，也沒有辦法避免。不過這個(gè)問題的影響是可以接受的，可以先承擔(dān)。

不朽體:遵循上面的“阻塞我的生命”，如果集群真的被一個(gè)DDL卡住，導(dǎo)致整個(gè)集群無法移動(dòng)，所有的寫請(qǐng)求都是Hang，那么可能會(huì)有人想到一個(gè)妙招，說快殺，直接在每個(gè)節(jié)點(diǎn)上輸入kill connection_id，以及其他類似的操作，那么這個(gè)時(shí)候，我不想看到的信息就被舉報(bào)了:你不是線程連接的擁有者這個(gè)時(shí)候， 有的同學(xué)可能會(huì)哭，但這種情況下，真的沒有好的解決辦法，或者等DDL執(zhí)行完成，或者直接殺死數(shù)據(jù)庫，快速重啟，快速恢復(fù)一個(gè)節(jié)點(diǎn)提交在線服務(wù)。 然后考慮集群中其他節(jié)點(diǎn)的數(shù)據(jù)增量同步。這個(gè)坑很大，也是Galera Cluster里最大的坑，需要非常小心，避免出現(xiàn)這樣的問題。

4. 適用場景

現(xiàn)在我們對(duì)Galera Cluster已經(jīng)足夠了解了，但是在什么情況下才能使用這樣一個(gè)“完美”的架構(gòu)呢？或者說，哪個(gè)場景不適合使用這樣的架構(gòu)？針對(duì)其缺點(diǎn)和優(yōu)點(diǎn)，可以揚(yáng)長避短。以下幾個(gè)方面可以用來理解其適用的場景。

強(qiáng)數(shù)據(jù)一致性:Galera Cluster可以保證很強(qiáng)的數(shù)據(jù)一致性，所以更適合要求高數(shù)據(jù)一致性和完整性的場景，比如事務(wù)。正是因?yàn)檫@個(gè)特點(diǎn)，Qunar.com將成為Galera Cluster的最大用戶。

多點(diǎn)寫入:這里要強(qiáng)調(diào)的是多點(diǎn)寫入的意義，不是支持以多點(diǎn)寫入的形式提供服務(wù)，更重要的是因?yàn)槎帱c(diǎn)寫入，DBA在正常維護(hù)數(shù)據(jù)庫集群的時(shí)候，不會(huì)影響業(yè)務(wù)，也不會(huì)真正意識(shí)不到，因?yàn)橹灰侵鲝膹?fù)制，就不可能有多點(diǎn)寫入，導(dǎo)致切換的時(shí)候必然會(huì)斷開舊節(jié)點(diǎn)，然后統(tǒng)一切換到新節(jié)點(diǎn)。這是無法避免的，但是支持多點(diǎn)寫入，切換時(shí)允許短時(shí)間的多點(diǎn)寫入，這樣舊的連接不會(huì)受到影響，只需要將新的連接路由到新的節(jié)點(diǎn)。這個(gè)特性對(duì)于交易業(yè)務(wù)來說也是非常理想的。

性能:Galera Cluster可以支持強(qiáng)一致性。毫無疑問，它還以犧牲性能為代價(jià)來爭取數(shù)據(jù)一致性。但有必要問一句:“犧牲性能會(huì)不會(huì)性能太差，這樣的架構(gòu)根本不能滿足需求？我在這里只想說，這是一個(gè)權(quán)衡的過程。QPS有多少服務(wù)是蓋拉集群無法滿足的？我覺得不多。在追求極高性能的時(shí)候，也許單個(gè)Galera Cluster是不能滿足需求的，但畢竟是少數(shù)，所以足夠了。Galera Cluster一定是MySQL里最好的。

5. 總結(jié)

綜上所述，Galera Cluster是MySQL數(shù)據(jù)一致性完全可靠的武器，使用中不用擔(dān)心數(shù)據(jù)延遲和數(shù)據(jù)不一致。DBA已經(jīng)完全擺脫了復(fù)雜的數(shù)據(jù)修復(fù)，解決了復(fù)制延遲和維護(hù)期間擔(dān)心影響業(yè)務(wù)的問題?？梢哉fGalera Cluster是DBA和業(yè)務(wù)系統(tǒng)的福音，也是MySQL發(fā)展的大勢(shì)所趨。希望它越來越好，希望越來越多的人用它來共同維護(hù)這個(gè)美好的環(huán)境。