[[194471]]

1. 何謂Galera Cluster

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

圖1 Galera Cluster架構(gòu)

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

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

2. 為什么需要Galera Cluster

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

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

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

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

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

3. Galera Cluster如何解決問題

3.1 Galera的引入現(xiàn)在已經(jīng)知道，Galera Cluster是MySQL封裝了具有高一致性，支持多點(diǎn)寫入的同步通信模塊Galera而做的，它是建立在MySQL同步基礎(chǔ)之上的，使用Galera Cluster時，應(yīng)用程序可以直接讀、寫某個節(jié)點(diǎn)的最新數(shù)據(jù)，并且可以在不影響應(yīng)用程序讀寫的情況下，下線某個節(jié)點(diǎn)，因為支持多點(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提供了基于驗證的復(fù)制，是一種樂觀的同步復(fù)制機(jī)制，一個將要被復(fù)制的事務(wù)(稱為寫集)，不僅包括被修改的數(shù)據(jù)庫行，還包括了這個事務(wù)產(chǎn)生的所有Binlog，每一個節(jié)點(diǎn)在復(fù)制事務(wù)時，都會拿這些寫集與正在APPLY隊列的寫集做比對，如果沒有沖突的話，這個事務(wù)就可以繼續(xù)提交，或者是APPLY，這個時候，這個事務(wù)就被認(rèn)為是提交了，然后在數(shù)據(jù)庫層面，還需要繼續(xù)做事務(wù)上的提交操作。

這種方式的復(fù)制，也被稱為是虛擬同步復(fù)制，實(shí)際上是一種邏輯上的同步，因為每個節(jié)點(diǎn)的寫入和提交操作還是獨(dú)立的，更準(zhǔn)確的說是異步的，Galera Cluster是建立在一種樂觀復(fù)制的基礎(chǔ)上的，假設(shè)集群中的每個節(jié)點(diǎn)都是同步的，那么加上在寫入時，都會做驗證，那么理論上是不會出現(xiàn)不一致的，當(dāng)然也不能這么樂觀，如果出現(xiàn)不一致了，比如主庫(相對)插入成功，而從庫則出現(xiàn)主鍵沖突，那說明此時數(shù)據(jù)庫已經(jīng)不一致，這種時候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òu)：真正的多點(diǎn)讀寫的集群，在任何時候讀寫數(shù)據(jù)，都是最新的。

同步復(fù)制：集群不同節(jié)點(diǎn)之間數(shù)據(jù)同步，沒有延遲，在數(shù)據(jù)庫掛掉之后，數(shù)據(jù)不會丟失。

并發(fā)復(fù)制：從節(jié)點(diǎn)在APPLY數(shù)據(jù)時，支持并行執(zhí)行，有更好的性能表現(xiàn)。

故障切換：在出現(xiàn)數(shù)據(jù)庫故障時，因為支持多點(diǎn)寫入，切的非常容易。

熱插拔：在服務(wù)期間，如果數(shù)據(jù)庫掛了，只要監(jiān)控程序發(fā)現(xiàn)的夠快，不可服務(wù)時間就會非常少。在節(jié)點(diǎn)故障期間，節(jié)點(diǎn)本身對集群的影響非常小。

自動節(jié)點(diǎn)克?。涸谛略龉?jié)點(diǎn)，或者停機(jī)維護(hù)時，增量數(shù)據(jù)或者基礎(chǔ)數(shù)據(jù)不需要人工手動備份提供，Galera Cluster會自動拉取在線節(jié)點(diǎn)數(shù)據(jù)，最終集群會變?yōu)橐恢隆?/p>

對應(yīng)用透明：集群的維護(hù)，對應(yīng)用程序是透明的，幾乎感覺不到。 以上幾點(diǎn)，足以說明Galera Cluster是一個既穩(wěn)健，又在數(shù)據(jù)一致性、完整性及高性能方面有出色表現(xiàn)的高可用解決方案。

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

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

Galera Cluster寫集內(nèi)容：Galera Cluster復(fù)制的方式，還是基于Binlog的，這個問題，也是一直被人糾結(jié)的，因為目前Percona Xtradb Cluster所實(shí)現(xiàn)的版本中，在將Binlog關(guān)掉之后，還是可以使用的，這誤導(dǎo)了很多人，其實(shí)關(guān)掉之后，只是不落地了，表象上看上去是沒有使用Binlog了，實(shí)際上在內(nèi)部還是悄悄的打開了的。除此之外，寫集中還包括了事務(wù)影響的所有行的主鍵，所有主鍵組成了寫集的KEY，而Binlog組成了寫集的DATA，這樣一個KEY-DATA就是寫集。KEY和DATA分別具有不同的作用的，KEY是用來驗證的，驗證與其它事務(wù)沒有沖突，而DATA是用來在驗證通過之后，做APPLY的。

Galera Cluster的并發(fā)控制：現(xiàn)在都已經(jīng)知道，Galera Cluster可以實(shí)現(xiàn)集群中，數(shù)據(jù)的高度一致性，并且在每個節(jié)點(diǎn)上，生成的Binlog順序都是一樣的，這與Galera內(nèi)部，實(shí)現(xiàn)的并發(fā)控制機(jī)制是分不開的。所有的上層到下層的同步、復(fù)制、執(zhí)行、提交都是通過并發(fā)控制機(jī)制來管理的。這樣才能保證上層的邏輯性，下層數(shù)據(jù)的完整性等。

圖2 galera原理圖

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

a. 本地執(zhí)行：這個階段，是事務(wù)執(zhí)行的最初階段，可以說，這個階段的執(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ā)送時，需要串行，這個就屬于Galera Cluster并發(fā)控制的一部分了。

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

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

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

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

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

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

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

發(fā)送FC消息的節(jié)點(diǎn)，硬件有可能出現(xiàn)問題了，比如IO寫不進(jìn)去，很慢，CPU異常高等

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

發(fā)送FC消息的節(jié)點(diǎn)，硬件壓力都沒有太大問題，但做得比較慢，一般原因是主庫并發(fā)高，但從節(jié)點(diǎn)的并發(fā)跟不上主庫，那么此時可能需要觀察這兩個節(jié)點(diǎn)的并發(fā)度大小，可以參考狀態(tài)參數(shù)wsrep_cert_deps_distance的值，來調(diào)整從節(jié)點(diǎn)的wsrep_slave_threads，此時應(yīng)該是可以解決或者緩解的，這個問題可以這樣去理解，假設(shè)集群每個節(jié)點(diǎn)的硬件資源都是相當(dāng)?shù)模敲粗鲙炜梢詧?zhí)行完，從庫為什么做不過來?那么一般思路就是像處理主從復(fù)制的延遲問題一樣。

檢查存不存在沒有主鍵的表，因為Galera的復(fù)制是行模式的，所以如果存在這樣的表時，主節(jié)點(diǎn)是通過語句來修改的，比如一個更新語句，更新了全表，而從節(jié)點(diǎn)收到之后，就會針對每一行的Binlog做一次全表掃描，這樣導(dǎo)致這個事務(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)致很多人放棄的原因。

DDL執(zhí)行卡死傳說：使用過的同學(xué)可能知道，在Galera Cluster中執(zhí)行一個大的改表操作，會導(dǎo)致整個集群在一段時間內(nèi)，是完全寫入不了任何事務(wù)的，都卡死在那里，這個情況確實(shí)很嚴(yán)重，導(dǎo)致線上完全不可服務(wù)了，原因還是并發(fā)控制，因為提交操作設(shè)置為串行的，DDL執(zhí)行是一個提交的過程，那么串行執(zhí)行改表，當(dāng)然執(zhí)行多久，就卡多久，直到改表執(zhí)行完，其它事務(wù)也就可以繼續(xù)操作了，這個問題現(xiàn)在沒辦法解決，但我們長期使用下來發(fā)現(xiàn)，小表可以這樣直接操作，大一點(diǎn)或者更大的，都是通過osc(pt-online-schema-change)來做，這樣就很好的避免了這個問題。

擋我者死：由于Galera Cluster在執(zhí)行DDL時，是Total Ordered Isolation(wsrep_OSU_method=TOI)的，所以必須要保證每個節(jié)點(diǎn)都是同時執(zhí)行的，當(dāng)然對于不是DDL的，也是Total Order的，因為每一個事務(wù)都具有同一個GTID值，DDL也不例外，而DDL涉及到的是表鎖，MDL鎖(Meta Data Lock)，只要在執(zhí)行過程中，遇到了MDL鎖的沖突，所有情況下，都是DDL優(yōu)先，將所有的使用到這個對象的事務(wù)，統(tǒng)統(tǒng)殺死，不管是讀事務(wù)，還是寫事務(wù)，被殺的事務(wù)都會報出死鎖的異常，所以這也是一個Galera Cluster中，關(guān)于DDL的聞名遐邇的坑。不過這個現(xiàn)在確實(shí)沒有辦法解決，也沒辦法避免，不過這個的影響還算可以接受，先可以忍忍。

不死之身：繼上面的“擋我者死”，如果集群真的被一個DDL卡死了，導(dǎo)致整個集群都動不了了，所有的寫請求都Hang住了，那么可能會有人想一個妙招，說趕緊殺死，直接在每個節(jié)點(diǎn)上面輸入kill connection_id，等等類似的操作，那么此時，很不愿意看到的信息報了出來：You are not owner of thread connection_id。此時可能有些同學(xué)要哭了，不過這種情況下，確實(shí)沒有什么好的解決方法(其實(shí)這個時候，一個故障已經(jīng)發(fā)生了，一年的KPI也許已經(jīng)沒有了，就看敢不敢下狠手了)，要不就等DDL執(zhí)行完成(所有這個數(shù)據(jù)庫上面的業(yè)務(wù)都處于不可服務(wù)狀態(tài))，要不就將數(shù)據(jù)庫直接Kill掉，快速重啟，趕緊恢復(fù)一個節(jié)點(diǎn)提交線上服務(wù)，然后再考慮集群其它節(jié)點(diǎn)的數(shù)據(jù)增量的同步等，這個坑非常大，也是在Galera Cluster中，最大的一個坑，需要非常小心，避免出現(xiàn)這樣的問題。

4. 適用場景

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

數(shù)據(jù)強(qiáng)一致性：因為Galera Cluster，可以保證數(shù)據(jù)強(qiáng)一致性的，所以它更適合應(yīng)用于對數(shù)據(jù)一致性和完整性要求特別高的場景，比如交易，正是因為這個特性，我們?nèi)ツ膬壕W(wǎng)才會成為使用Galera Cluster的第一大戶。

多點(diǎn)寫入：這里要強(qiáng)調(diào)多點(diǎn)寫入的意思，不是要支持以多點(diǎn)寫入的方式提供服務(wù)，更重要的是，因為有了多點(diǎn)寫入，才會使得在DBA正常維護(hù)數(shù)據(jù)庫集群的時候，才會不影響到業(yè)務(wù)，做到真正的無感知，因為只要是主從復(fù)制，就不能出現(xiàn)多點(diǎn)寫入，從而導(dǎo)致了在切換時，必然要將老節(jié)點(diǎn)的連接斷掉，然后齊刷刷的切到新節(jié)點(diǎn)，這是沒辦法避免的，而支持了多點(diǎn)寫入，在切換時刻允許有短暫的多點(diǎn)寫入，從而不會影響老的連接，只需要將新連接都路由到新節(jié)點(diǎn)即可。這個特性，對于交易型的業(yè)務(wù)而言，也是非?？是蟮?。

性能：Galera Cluster，能支持到強(qiáng)一致性，毫無疑問，也是以犧牲性能為代價，爭取了數(shù)據(jù)一致性，但要問：”性能犧牲了，會不會導(dǎo)致性能太差，這樣的架構(gòu)根本不能滿足需求呢?”這里只想說的是，這是一個權(quán)衡過程，有多少業(yè)務(wù)，QPS大到Galera Cluster不能滿足的?我想是不多的(當(dāng)然也是有的，可以自行做一些測試)，在追求非常高的極致性能情況下，也許單個的Galera Cluster集群是不能滿足需求的，但畢竟是少數(shù)了，所以夠用就好，Galera Cluster必然是MySQL方案中的佼佼者。

5. 總結(jié)

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