【IT168 技術】MySQL資料庫從誕生以來就以其簡單、易用、開源為其主打特點，成為不少開發者首選的資料庫系統。集團在2008年開始提出"去IOE"的口號，其中，使用大量的MySQL，配合業務的改造替代原有的商業版Oracle系統。自此集團邁入了MySQL資料庫的時代。根據阿里交易型應用的特點，以及雙十一這樣業界罕有的需求推動下，我們在官方的MySQL基礎上增加了非常多實用的功能、性能補丁，打造了AliSQL這個業界響噹噹的MySQL分支品牌。
時間很快走到2014年，隨著業務高速的增長，同城主備AliSQL部署的方式已經無法滿足阿里對可擴展的部署、國際化、以及容災方面的需求。「異地多活」成為了公司應用的新標準。「異地多活」也給底層的資料庫提出了新的容災要求。傳統的Master-Slave架構下，主備如果不使用強同步模式就會存在數據丟失的可能，然而強同步下一旦有節點異常則整體不可服務。而且這套架構下需要HA工具來進行選主的仲裁和控制。過去阿里巴巴的DBA們開發了高效可靠的HA以及一整套工具和流程來做主備切換後數據和日誌的校驗和訂正。然而我們相信技術的發展能帶來更大的運維便利性以及更好的用戶體驗。 以Google Spanner以及Amazon Aruora 為代表的NewSQL系統為資料庫的數據一致性給出了與以往不同的思路： 基於一致性協議搭建分布式的多副本資料庫。
AliSQL X-Cluster 介紹
AliSQL X-Cluster(本文中簡稱X-Cluster)是阿里巴巴資料庫團隊推出的兼容MySQL 5.7，提供數據強一致功能，支持全球部署的分布式資料庫集群產品。
說到AliSQL X-Cluster就不能不提其分布式核心，一致性協議。
X-Paxos是阿里巴巴自主研發的一致性協議庫，目標是填補市面上高性能、易接入的一致性協議庫的空白。而市面上已開源的一致性協議實現，包括etcd以及其他廠商等都存在或性能不夠，或功能上無法滿足複雜的現實應用場景需求的問題。 有了X-Paxos，可基於它打造一套強一致的分布式系統，X-Cluster是第一個接入X-Paxos生態的重要產品，利用了X-Paxos實現了自動選主，日誌同步，集群內數據強一致，在線集群配置變更等功能。同時X-Cluster基於MySQL生態，兼容最新版本的MySQL 5.7，集成了AliSQL過去的各種功能增強。 MySQL的用戶可以零成本遷移到X-Cluster上。
整體架構
先來看一下X-Cluster的基本架構：
上圖展示的是一個部署三個實例的Cluster集群。X-Cluster是一個單點寫入，多點可讀的集群系統。在同一時刻，整個集群中至多會有一個Leader節點來承擔數據寫入的任務。相比多點寫入，單點寫入不需要處理數據集衝突的問題，可以達到更好的性能與吞吐率。
X-Cluster 的每個實例都是一個單進程的系統，X-Paxos被深度整合到了資料庫內核之中，替換了原有的複製模塊。集群節點之間的增量數據同步完全是通過X-Paxos來自驅動，如何複製，從哪個點回放不再需要運維人員或者外部工具來介入。 X-Cluster為了追求最高的性能，利用MySQL的Binlog進行深度改造和定製來作為X-Paxos的Consensus日誌，實現了一系列的X-Paxos日誌接口，賦予X-Paxos直接操縱MySQL日誌的能力。
為了保證集群數據的一致性以及全球部署的能力，在事務提交、日誌複製回放以及恢復上X-Cluster都進行了重新設計。
事務提交、複製流程
X-Cluster的複製流程是基於X-Paxos驅動Consensus日誌進行複製。
Leader節點在事務prepare階段會將事務產生的日誌收集起來，傳遞給X-Paxos協議層後進入等待。X-Paxos協議層會將Consensus日誌高效地轉發給集群內其他節點。當日誌在超過集群半數實例上落盤後 X-Paxos會通知事務可以進入提交步驟。否則如果期間發生Leader變更，期間prepare的事務會根據Paxos日誌的狀態進行相應的回滾操作。相比原生MySQL，日誌傳輸採用了多線程、異步化、Batching、Pipelining等優化手段，特別是在長傳鏈路的場景中，效率提升明顯。
Follower節點也使用X-Paxos進行日誌的管理操作，為提升接收效率，收到Leader傳遞過來的日誌以後將日誌內容Append到Consensus Log末尾，Leader會異步的將達成多數派的日誌的消息發送給Follower，Follower的協調者線程會負責讀取達成多數派的日誌並加以解析，並傳遞給各個回放工作線程進行並發的數據更新。 Follower的並發回放可以有多種方式，包括按照Leader上的Group Commit維度或者是按照表級別的維度，未來會引入最新的writeset方式來精確控制最大並發。
Failover
X-Cluster 只要半數以上的節點存活就能保證集群正常對外服務。 因此當少數的follower節點故障時並不影響集群的服務能力。當Leader節點故障時會自動觸發集群的重新選主流程。 選主流程由X-Paxos驅動，在Paxos協議的基礎上，結合優先級推選出新的Leader節點。
對於X-Cluster而言，failover_time = election_time + apply_time
election_time代表協議選主的時間，一般在10s左右， apply_time是數據應用日誌的時間，取決於回放的速度，優秀的並行回放算法能把應用日誌的時間控制在10s之內。
相對來說之下Leader節點故障是一個相對複雜的場景，故障包括了實例崩潰、伺服器宕機、網絡隔離等等。
如上圖所示，一個三節點的X-Cluster集群，左上的Case是原Leader A節點宕機，因此B節點和C節點會在較長的時間內收不到Leader的心跳，因此在一個選舉超時周期後，B節點開始嘗試推選自己為Leader， 並且C節點同意， 那麼B成為新的主節點，恢復服務能力。
左下的Case 是原Leader A節點發生網絡分區，此時在選舉超時後，BC兩個節點的行為和之間的Case類似。 A節點由於無法將心跳和日誌發送給BC兩個節點在超時後會降級，然後不斷嘗試選自己為Leader，但是因為沒有其他節點的同意，達不成多數派，一直都不會成功。當網絡分區恢復後，A收到B節點的心跳，觸發Leader stickness機制，A降級成為Follower，整個集群保持一致。
在選舉的過程中是否能成為Leader需要根據節點的日誌情況來決定。X-Cluster 承諾在failover的情況下不會丟失提交的數據。Paxos協議保證了在集群恢復後一定能保證所有的節點日誌一致。那麼只要數據是按照日誌進行回放，就能保證所有節點的狀態機(數據)一致。 成為Leader的節點要求有最長的日誌。如右上所示，假設A節點宕機或者分區前已經把3號日誌複製到了B節點，那麼在重新選舉後，B節點由於日誌較多，因此能夠被選舉成Leader。 在成為Leader後B節點會嘗試將3號日誌再複製到C節點。最終，ABC三個節點都會有1，2，3號日誌，因此數據也是一致的。
AliSQL X-Cluster的優化特性
X-Cluster擁有一系列的新功能和特性，以滿足不同類型的應用對於功能和性能上的需求。
跨地域部署
X-Cluster的一個顯著功能就是能夠支持跨地域部署，在跨域的情況下也能保證集群數據強一致，擁有城市級容災的能力。即使某個城市的機房全部宕機，只要保證集群多數派節點存活，所有的數據都不會丟失。 依賴X-Paxos以及資料庫內核中異步化工作線程的改造，在數十毫秒的網絡RTT(Round Trip Time)下，X-Cluster依然有非常高的吞吐性能。擁有了跨地域部署的能力,X-Cluster的部署方式是非常靈活的。 業務可以根據實際的業務情況以及不同的容災級別需求，選擇同機房容災，機房容災，城市容災部署，並且可以在不同的容災級別之間靈活切換。
集群的動態配置和選舉
X-Cluster支持在線集群配置變更。包括：
·增加節點下線節點
·修改節點類型為一致性節點或者是只讀節點
·修改節點優先級
·修改集群的Leader
·修改只讀節點複製源
所有的上述修改配置的過程在線進行，不會阻塞業務的正常運行，集群配置的變化也會嚴格按照Paxos協議進行，記錄日誌並且對應的推動狀態機變更，並且有完善的恢復機制。保證最終集群內配置達成一致，不會因為集群配置變更過程中的異常導致腦裂或者其他配置出現終態不一致的問題。X-Cluster集群的節點從功能上看有兩個類型， 包括參與選主與多數派協議的一致性協議節點還有隻讀節點。一致性協議節點是X-Cluster的基礎。目前一個X-Cluster集群支持至少1個一致性節點，至多99個一致性節點。 只讀節點可以無限擴展。 用戶可以從一開始的單節點集群開始，後續不斷根據需求擴展不同類型的節點。
優先級
應用往往對於容災後新主節點是有要求的，在原先的主節點意外宕機後，新主如若落在了一個低規格的節點， 那麼對於應用來說是很難接受的服務降級。 X-Cluster 支持同一個集群中的節點擁有不同的優先級，用戶可以根據實際的部署需要，在配置集群時為每個實例節點設置優先級。
優先級功能主要包括以下兩方面：
·權重化選主
·策略化多數派
權重化選主代表選主的順序權重。只要在選舉的時候沒有網絡隔離，選舉Leader的順序會按照集群存活節點的權重順序進行。權重越高的節點，就有更大的優先級被選為Leader。我們實現了兩段式的選舉時間，第一階段是集群內統一的租約時間，而二階段是根據權重來決定，權重越大的節點時間越短，也就是會越早發起自選舉。 除此之外，還有一重權重檢測機制來保證權重優先級，節點上任時會廣播檢測一遍所有能夠聯通的集群內節點，如果發現權重更高的節點會主動發起一次Leader Transfer將Leader角色過繼過去。 權重化選主在跨地域部署的場景下尤其重要。 跨地域的部署業務和資料庫之間的訪問延時會非常敏感，如果Leader節點隨機的切換到了另一個地域的機房可能會導致應用大規模的訪問異地實例，大幅增加客戶端的響應時間。 權重化選主可以完美解決此問題。 按照應用的部署需求進行動態設置，非常靈活。
策略化多數派是指在事務提交日誌同步過程中，哪些節點必須要日誌複製完成。複製優先級分為兩檔，強複製和弱複製。標準的Paxos只要超過半數的節點同步日誌即可推進狀態機，但是由於每個連接會自動分配路由的問題，可能在跨Region的訪問中RTT時間會有誤差。那麼為了縮短網絡/節點故障後按照選主優先級重新選主並繼續服務的時間間隔，我們可以配置在規定日誌複製到多數節點的基礎上必須還要複製到了所有強複製的節點才可以推進狀態機並返回客戶端事務提交成功的響應。這是一個類Max protection模式的設計，如果檢測到強一致節點宕機，可選擇適當的降級。
低成本副本管理
在X-Cluster中，副本按照是否有數據狀態機分為普通型(Normal)，日誌型(Log)兩類。 普通型擁有全部的功能;日誌型只擁有日誌不包含數據。 如果日誌型節點還是一個參與Paxos投票的一致性節點，那麼它只有投票權，沒有被選舉權。
之所以要創建不同的類型的副本，還是出於應用需求以及成本控制的考慮。相比傳統的兩節點主備複製，X-Cluster的常規同城部署方式是三節點。
日誌型副本是作為降低部署成本的一種選擇。日誌型副本只存儲日誌，不需要存儲數據，也不需要回放日誌更新數據。因此無論是存儲還是CPU的開銷，日誌型副本相比普通副本都有很大的優勢。在實際應用規劃中，非常適合來當作容災型的節點部署。
只讀節點管理
如上圖所示，X-Cluster集群中的只讀節點可以從任何一個一致性節點複製日誌，這不僅是考慮到如果所有節點的日誌都從Leader節點複製會對Leader節點造成過大的網絡和IO瓶頸，而且由於跨區域部署下不同地域的數據狀態機可能會有延時，設置了讀寫分離的用戶在特定的場景下需要有特定的只讀狀態延時的要求。 但是這時的問題就是如果某個一致性節點發生了宕機，那麼和它建立複製關係的只讀節點應該如何進行災備聯動? 作為一個自運維的資料庫服務，X-Cluster自然要解決好這個問題。X-Cluster定義了Learner Source Group。 每個Group是一個只讀節點的容災單元。 當Group內某個一致性節點發生意外狀況(宕機或者網絡隔離)集群會根據Group的配置，將掛載在故障節點下的只讀節點配置到Group中另外一個正常工作的節點下進行數據同步。
高性能日誌
MySQL系統在開啟主備複製的情況下除了會記錄Binlog之外，在備庫上還會記錄一份RelayLog。即從庫通過指定對應主庫的Binlog位置去同步一份二進位日誌寫入RelayLog，供複製線程讀取和回放。在X-Cluster中，只使用一份日誌進行節點間的同步，利用X-Paxos的插件式日誌模塊的特性，每個節點有一份Consensus日誌。這樣既方便了對Consensus日誌的管理，也降低了日誌存儲以及讀寫的開銷。 Consensus Log 擁有Append，Get，Truncate以及Purge等基本接口，它的控制權完整地交給了X-Paxos，由X-Paxos進行控制。 除此之外，X-Cluster為Consensus Log設計了日誌索引和日誌緩存、預讀機制，極大的提升了日誌模塊的性能保證一致性協議運作的高效性。
異步化事務提交
傳統的MySQL都是 One Thread per Connection的工作模式， 在引入線程池後是以一個線程池孵化一定數量的工作線程， 每個線程負責處理一次query的解析、優化、修改數據、提交、回網絡包等等。集群需要跨地域部署下，一次事務的提交由於需要在集群之間同步事務日誌，受限於網絡的RTT的限制，會達到數十毫秒的級別，那麼對於一個普通的寫事務來說，大量的時間會耗費在同步節點日誌等待事務提交的過程。在大壓力下，很快資料庫內部的工作線程會耗盡， 吞吐達到瓶頸。 如果一味的放大資料庫內部的工作線程數目，那麼線程上下文的代價會大幅增加。 如果將整個事務的提交異步化，將工作線程從等待X-Paxos日誌同步中解放出來，去處理新的連接請求，在大負載下可以擁有更高的處理能力。
異步化改造的說明示意如下圖所示：
X-Cluster的異步化提交核心思想是將每個事務的請求分成兩個階段，提交之前一個階段，提交和回包一個階段。兩個階段都可以由不同的工作線程來完成。 為了完成異步化的改造，X-Cluster增加了等待同步隊列和等待提交隊列，用於存儲處於不同階段的事務。前者隊列中的事務是等待Paxos多數派日誌同步的事務，後者是等待提交的事務。 當用戶發起Commit/Rollback/XA_Prepare時， 處理用戶連接的線程池Worker產生事務日誌並將事務上下文存儲到等待同步的隊列中。 等待同步隊列的消費由少量數目的worker線程來完成，其餘工作線程可以直接參與其他任務的處理。 事務等待多數派完成後會被推入等待提交隊列。這個隊列裡的事務都是可以被立即提交的。所有的worker線程發現該隊列裡有事務，就可以順道取出來執行提交操作。 這樣一來，系統中只有少數的線程在等待日誌同步操作， 其餘的線程可以充分利用CPU處理客戶端的請求。 X-Cluster以這樣的思路為指導原則， 結合MySQL的Group Commit邏輯，將原有需要等待的操作全部異步化，讓Worker線程可以去執行新的請求響應。在測試中，異步化改造在同城部署的場景中相比同步提交有10%的吞吐率提升，跨區域的部署後有幾倍的吞吐提升。
熱點更新
熱點更新原本就是資料庫的一個難題，受制於行鎖競爭，性能吞吐一直很難提升上去。X-Cluster面對跨域場景下的長傳網絡更加是雪上加霜，提交的時間變長，事務佔據行鎖的時間也顯著增加。
為了解決此問題，X-Cluster在單機版AliSQL的熱點功能之上優化了複製，使得在保證數據強一致的情況下，熱點更新性能提升200倍。
如上圖所示，X-Cluster針對熱點行更新的基本思路是合併多個事務對同一行的更新。為了讓批量的更新事務能夠同時進行提交，X-Cluster增加了一種新的行鎖類型——熱點行鎖。熱點行鎖下，熱點更新的事務之間是相容的。 X-Cluster為了保證數據的一致性，對同一批的熱點更新事務日誌打上特殊標誌， X-Paxos會根據這些標誌將這一整批事務的日誌組成一個單獨的網絡包進行集群間的數據同步，保證這些事務是原子的提交/回滾。除此之外為了提升日誌回放的效率，X-Cluster將每個批次事務中對於熱點行的更新日誌也做了合併。
一體化的客戶端和服務端
X-Cluster有完整的Client-Server生態。 所以整個系統不需要外部組件的介入，能夠自封閉的成為一個生態閉環。 作為客戶端的X-Driver能夠訂閱Server端發生的一切改變，從而進行自動尋主，實例列表動態維護等功能。 客戶端的元數據就保存在X-Cluster服務內部。相比外置的元數據中心，這套自封閉體系能夠以最快的時間獲取到準確的集群變化。降低集群變更對用戶的感知程度。
優化的備份以及數據訂閱體系
基於強大的X-Paxos體系，日誌備份以及數據訂閱系統都能夠以日誌訂閱者的方式接入進來。 由於有了X-Paxos的全局唯一位點支持，這些訂閱系統的failover不再會有難以找到準確位點的困擾。而且由於X-Paxos是流式的推送日誌消息，因此數據的實時性也能大幅改進。
AliSQL X-Cluster 實戰部署方案
X-Cluster最為經典的兩個部署方案是同城3副本，兩份數據一份日誌。以及跨地域5副本，四份數據一份日誌。分別用於滿足機房級容災和城市級容災需求。這裡的副本概念指的都是一致性節點的部署，只讀節點部署不影響容災能力。這兩類經典的部署方案都是考慮了可用性以及成本之間的權衡，以較小的代價換來目標的容災能力。
X-Cluster的同城部署三副本能夠方便的實現零數據丟失的實例容災以及機房級容災。 相比主備方式，額外增加了一個日誌節點，換取強一致以及可用性。
三地五實例(四數據、五日誌)能夠保證城市級容災， 如圖所示，任何一個城市的節點全部宕機都不會影響到集群可用性，5個節點中至少還有3個節點是能夠正常運行的。 在日常運行中，5節點在每次事務提交的時候必定需要將日誌同步到3個節點，因此必然會出現一次跨域的網絡同步，這也就是長傳鏈路網絡場景，X-Cluster對於慢網絡的優化正是應對類似這樣的需求。
AliSQL X-Cluster 性能表現
我們使用了三節點部署的方式，分別在同域三機房、跨域三機房的網絡環境下進行了測試。 測試工具使用標準的Sysbench的 insert/oltp， Insert測試下，並且每個事務中只包含一條插入語句，屬於密集的小事務場景， 而相反的OLTP是讀寫大事務。 針對熱點環境，測試的場景是改造update_non_index ， 使更新同一行數據。只讀場景不在本次測試的範疇內，原因是只讀不涉及到節點的日誌、數據同步，因此可以認為只讀測試對於X-Cluster這樣的分布式系統是沒有意義的。所有的測試，數據量為10張表，每張表20萬條記錄。
作為對比，我們使用了最新的開源單機版MySQL 5.7.19 以及該版本下的Group Replication。Group Replication在測試中關閉限流。
測試機均是64core 256G內存 PCIE SSD。
測試同域下的集群，Insert我們使用300並發線程、 OLTP使用400並發線程， 熱點更新使用300並發線程。
在同一個域下，X-Cluster的吞吐和響應時間表現都是非常出色的，甚至略好於單機版本的MySQL 5.7.19。 相比Group Replication， 在本次測試的壓力下，Insert case X-Cluster有超過一倍的吞吐以及55%左右的響應時間，OLTP case X-Cluster 有超過5%的吞吐以及接近70%的響應時間表現。
測試跨域下的集群需要大量的連接來保證吞吐，因此Insert使用2000並發線程，OLTP使用700並發線程，熱點更新使用2500並發線程。
當集群部署在不同域時，X-Cluster和Group Replication相比同域的部署下吞吐都有下降，響應時間收到物理網絡延遲的影響也有顯著提高，然而在Insert case下，X-Cluster仍然可以達到超過單機版50%的吞吐，領先Group Replication 5倍，響應時間只有GR的四分之一。OLTP case下，X-Cluster 的吞吐領先Group Replication接近4倍，響應時間只有三分之一。
熱點更新是X-Cluster的一大亮點功能， 根據測試結果，無論是同域還是跨域部署， X-Cluster的吞吐和響應時間表現都要遠遠超過單機MySQL和Group Replication。
AliSQL X-Cluster正確性保障
分布式系統的測試是非常複雜的，因為沒有人能夠通過窮舉來羅列所有可能出現的情況。簡單的接口測試和性能回歸也只能覆蓋一小部分場景，無法來衡量一個分布式系統版本的質量。只有日復一日的測試以及線上系統的正常運行能夠真正地說明分布式系統的魯棒性。
X-Cluster最大的挑戰就是保證其基於分布式一致性協議實現的正確性。經過實踐證明，灰盒測試時最有效的手段。X-Cluster集成了X-Paxos，X-Paxos項目本身有一系列的測試框架用於發現和回歸。除此之外X-Cluster基於tc、systemtap等工具構建了多種多樣模擬網絡異常、實例宕機、I/O異常的環境。在這套環境下網絡分區、丟包、各種IO異常，各種實例宕機可以隨機組合。同時使用benchmark工具對每個節點施加大壓力的讀寫，定期的去校驗集群中不同節點的數據以及日誌的一致性。 一致性相關所有的操作都會記錄在X-Cluster專門的日誌中，方便追溯集群節點間的交互行為。 數據和日誌的最終一致性校驗交由外部系統來完成。阿里內部有專門的分片校驗系統可以做X-Cluster不同節點的全量數據校驗。 Consensus日誌解析工具可以快速解析日誌內容進行比對。這套測試環境幫助我們發現了非常多的系統BUG。包括實例恢復的BUG，網絡異常導致的BUG等等。我們認為一個穩定的版本的標準是一定需要通過這個場景長時間的測試並各種表現符合預期。
除了數據和日誌的最終一致性，對於數據的線性一致，事務隔離性，我們引入了Jepsen工具。 Jepsen幫助了大量分布式系統發現了分布式協議和實現的正確性問題。我們為X-Cluster專門構造了一系列的測試用例來儘可能覆蓋各種異常場景，來發現系統在隔離性和一致性上的問題。
AliSQL X-Cluster與同類的對比
AliSQL X-Cluster不是第一個基於MySQL的強一致集群方案，然而是最適合阿里這樣體量的公司的資料庫解決方案。對比下面這些同類產品：
Galera
Galara是MariaDB支持的MySQL集群版本，支持強同步，支持多點寫入，支持自動的集群配置以及節點Failover， 支持行級別的並行複製，支持原生的MySQL客戶端。在這套架構下，Slave不會有延時，任意節點讀到的都是一致數據，不會有事務數據丟失，讀寫可擴展。
Galera的集群通信是用了一種基於單令牌環的Totem組播協議。 為了能支持多點寫入，主機在收到寫請求後，會原子廣播到組內所有的機器，由它們各自的事務管理層來決定是提交或者回滾。組播由於是P2P的通信，隨著節點數增加，延時會放大，響應時間會變慢，並且只適用於低延時的區域網。 除此之外組播還有一個問題，如果組內的某臺機器宕機，組播會超時，在踢掉fail的機器重新確定組內成員關係之前，整個集群不可服務。
Galera 採用了專門的文件gcache進行增量狀態複製，gcache不做任何他用，因此gcache本身需要 額外的計算和存儲代價進行維護
Group Replication
Group Replication是MySQL 官方出品的集群方案。Group Replication多少是借鑑了Galera的思想，同樣支持多主多點寫入。Group Replication實現了一個X-COM的通信層，其新版本中已經使用了Paxos算法。目前一個GR集群中最多可以有9個節點，響應延時相對穩定，在節點同步日誌層面， GR使用Binlog，相比Galera更加的通用。
Group Replication的協議層複製是XCOM，且在複製中強依賴GTID。在測試中的性能表現，特別是跨域部署下還達不到需求， 目前的版本中也仍然有大量的BUG在修復，完全可用於生產環境還有待後續版本的穩定性和性能提升。
總結
X-Cluster是針對數據質量要求較高的用戶推出的全新的資料庫解決方案。X-Cluster不僅能夠享受到開源社區帶來的紅利，其中涉及一致性的關鍵的技術也能夠做到完全的自主、可控，能夠針對業務的需求進行靈活的變更。未來 X-Cluster會在此基礎上做更多的優化，例如支持多分片的Paxos， 多節點提供強一致讀等功能。隨著X-Paxos和AliSQL的不斷進化，X-Cluster也給大家會帶來更多的驚喜。
參考文獻
【1】Group Replication is GA with MySQL 5.7.17 – comparison with Galera http://lefred.be/content/group-replication-vs-galera/
【2】MySQL HighAvailability Blog http://mysqlhighavailability.com/tag/mysql-group-replication/
【3】Introduction to Galera https://www.slideshare.net/henrikingo/introduction-to-galera
【4】 GALERA CLUSTER DOCUMENTATION
http://galeracluster.com/documentation-webpages/