MySQL集群新技術——MGR

有一種技術，讓MySQL復制不再是Change Master To，也不再讓你手動Failover，而且還能多點寫入，你聽了會不會很興奮？天下還有這樣的復制技術么？

背景

確保數據庫穩定運行是DBA核心價值之一。通過搭建災備庫，利用復制技術同步主庫的數據更新，在主庫不可用時，啟用備庫可以快速恢復數據庫服務，減少對業務的影響，同時，備庫也可用於負載均衡、數據備份、統計報表等場景。帶來諸多好處的同時，自然也有其弊端：增加了額外的硬件、維護成本，以及復制中主從數據延遲或不一致等多種問題。MySQL在3.23.15版本中新增了復制功能，接下來是一系列的增強和優化：row based，半同步復制，GTID，多線程，多源復制，組復制等，本文重點討論2016年底官方GA的Group Replicaion(下文簡稱MGR)。

復制技術

上圖為事務提交過程中不同的復制技術的處理方式，分為異步復制，半同步復制，驗證復制和集群復制。

• 異步復制。這是當前廣泛使用的復制方式，事務在主庫完成提交，binglog中記錄事務數據，從庫同步binlog並在本地應用binlog中的事務。這種方式對主庫性能幾乎沒有影響，最大的問題是同步延遲，在主庫發生故障時無法保證從庫已經完成數據同步，從而造成數據丟失。

• 半同步復制。5.5推出的新功能，主庫在事務提交時，保證至少收到一個從庫已經收到該事務數據的確認信息之后完成事務提交，這對主從間的網絡通信有一定要求，當然也減低了主從之間的復制延遲，減少切換過程中的數據丟失。

• 驗證復制。MGR就是基於驗證的復制技術，也是本文的主角。在半同步復制的基礎之上，各個節點接受事務數據，並進行沖突驗證，所有節點通過驗證后再進行本地提交，反之回滾。這種方式以集群方式提供服務，可多節點寫入，並確保數據的強一致性。當然，沖突檢測、集群通信等額外的邏輯會帶來整體的性能下降。

• 集群復制。這種機制下，各節點獲得事務數據並進行本地提交，由仲裁者決定最終提交或回滾。分兩種方式：事務源仲裁和集群選取仲裁者。

對比不同的復制機制，可以看出復制技術一直在復制節點（從庫）對事務的響應策略上不斷地優化，從異步復制中事務完成后通過binlog同步，到半同步中響應接收，驗證復制中的沖突檢測，到集群復制的本地應用。隨着復制節點對事務的響應方式發生變化，數據一致性不斷加強，復制延遲不斷減低，而整體的性能也會隨之降低。選擇哪種復制技術是在數據一致性和性能兩者之間的一個權衡，異步復制和半同步業內已經使用廣泛，下面我們討論MGR的原理和特性，為MySQL高可用選型提供一些參考。

MySQL Group Replication

上圖是3節點的MGR集群結構，對於應用來說，可以選擇訪問（讀寫）集群任何一個節點。對於MySQL Server來說，在事務提交之前和普通的MySQL Server沒有差別，事務提交時，先將事務廣播到集群，各節點進行沖突檢測並返回結果，最后整個集群進行事務的提交或回滾。

MGR架構

MGR中幾個重要的組件：

• API層。負責完成和MySQL Server的交互，獲取server的狀態，截獲事務提交，干涉事務提交或者回滾。

• 組件層。特定功能的組件，Capture負責收集事務執行相關信息，Applier負責應用集群事務到本地，Recovery負責新節點的數據恢復

• 復制層。負責沖突驗證，接收和應用集群事務。

• 集群通信層。 基於Paxos協議的集群通信引擎以及和上層組件的交互接口。

集群狀態

在MGR中的節點狀態遷移：

組成集群的所有節點的狀態集合就是集群狀態，若干個節點狀態的變化帶來整個集群的狀態變化。節點在進行數據同步的同時，也需要同步集群狀態，感知所屬集群的狀態變化，比如節點的加入，離開。

集群通信

作為MGR的核心，集群通信引擎完成集群成員之間的狀態通信，集群狀態決議，事務的 廣播等，保證集群內成員執行同樣的事務序列，並最終達成一致集群狀態的變化。

Paxos協議

分布式系統中需要解決一個重要問題就是各節點對某一個狀態或變化達成一致。在MGR 集群中，多個節點寫入數據，如何保證集群內成員執行同樣的事務序列，並最終達成一致,以及節點故障時主集群的選舉。

Paxos算法用於解決上面這些問題。

故障探測

復制技術的出現就是為了解決單點問題。對於每一個節點來說，單點故障都有可能發生。MGR集群中，節點之間保持心跳檢測，每個節點從自身出發感知集群中其他節點的變化。

正常運行時，任意2個節點都可以正常通信。如果節點A對節點B的檢測失敗，則發起一個對B節點狀態的質疑，之后整個集群進行決議，如果其他節點均探測失敗，則集群決定剔除節點B，並同步改信息到所有在線節點。對於節點B，他會發起對所有節點的質疑，但無節點與其達成一致，則為無效的質疑。

集群選舉

選舉的目的其實是確定主集群是否存在，按照多數服從少數的原則，選舉過程中，多數達成一致的節點組成了主集群。

• 節點數為1，則為單點。

• 節點數為2，任何一個節點故障都無法進行選舉-參與選舉的節點總小於節點數。

• 節點數為3，在一個節點故障時，其余2個節點可以做出一致選舉節點數為n，n = 2 x f + 1，則可以當有小於f個節點故障時，集群可以完成主集群選舉。

• 這也是為什么MGR推薦至少3節點部署的原因，那是不是一定要奇數個節點呢，從選舉 的角度看，只要大部分節點達成一致即可，和節點總數奇偶無關。

網絡分區

如果一個集群由於網絡原因，形成了2個或多個子集群，分2種情況：

• 子集群中存在一個節點數大於(n-f),則該集群成為主集群，選舉可正常進行。

• 反之，則需要人為指定主集群成員。

事務驗證

MGR中，當事務在某個節點提交時，該節點並不會馬上提交，而是通過MGR插件將事務廣播到集群中，在集群通信中，存在一個動態的全局事務隊列，所有節點提交的事務都帶有全局唯一標識，並以其進入隊列的時間點確定先后順序。對於這個全局的事務隊列：

1. 所有的節點都以此隊列進行事務的提交，則所有節點總是以相同的順序提交同樣的一系列事務，保證了整個集群的數據強一致性。

2. 事務進入隊列后，所有節點都會進行沖突驗證，對於在不同節點提交且有沖突的事務，總是先進入隊列的事務通過驗證，而其他的則失敗。

3. 此隊列的維護以及通過此隊列完成的事務驗證過程既是驗證復制的重要環節也是性能損耗點。

4. 事務沖突的驗證目標隊列為隊列中先於其進入隊列的事務。

驗證的原理就很清晰了，MGR要求所有表必須有主鍵，在全局事務隊列中進行主鍵沖突檢測，就可以驗證正在驗證的事務中，是否存在與隊列中事務有相同的主鍵，存在則驗證失敗，反之通過。

節點恢復

此過程發生在新節點加入集群時，也就是節點狀態中的RECOVERING。在成為一個在線節點之前，新加入節點需要完成數據的同步和追平。

1. 備份導入。為減少對donor節點的影響，建議使用最近的備份初始化新節點，這樣新節點和集群的數據延遲就相對較少，而且在后續步驟中，采用異步復制來同步數據，如果初始化的備份時間點之后的binlog已經刪除，則會導致無法同步。

2. Donor節點選擇。新節點會選擇一個在線節點作為donor節點，donor節點提供新節點與它的延遲數據。同時，集群各節點寫入一個view change 事件到binlog中，此事件用於新節點判斷是否已經同步完延遲數據。

3. 數據同步。新節點開始同步donor節點，並開始參與集群通信，緩存集群事務。

4. 數據追平。當和dornor節點完成同步后，新節點開始應用步驟3中緩存的集群事務，當緩存數據全部應用，整個恢復過程完成。

Flow Control

由於各節點在本地完成事務應用，如果各節點的吞吐量（集中在IO上）不一樣甚至差距較大，則會導致在一個時間點上各節點的數據不一致（臟讀）。因而需要對整個集群的壓力進行控制，盡可能使集群在保證一致性的基礎上以最大吞吐量運行。流控制主要做兩件事情：監控和控制。

• 監控 。周期性（1秒）收集節點隊列長度和事務信息並同步到集群。

• 控制。在一個監控周期內，根據統計監控數據來決定下一個周期整個集群的事務數。這個事務數由集群中性能最差的節點的性能數據決定。

如果啟用流控制，節點上驗證隊列，應用隊列的堆積長度達到相應的配置值就會觸發流控制，相關參數：

group_replication_flow_control_mode  是否開啟流控制
group_replication_flow_control_certifier_threshold  驗證隊列堆積上線
group_replication_flow_control_applier_threshold   應用隊列堆積上線

建議

1. 穩定且良好的網絡環境。MGR集群中節點中會頻繁地通信，狀態同步，事務同步都直接影響整個集群的性能。穩定的網絡環境可以減少集群狀態的變化，良好的網絡性能可提高集群吞吐量。

2. 節點硬件配置一致。性能最差的節點決定集群的性能，各節點的硬件差異帶來節點性能的差異，則集群在處理事務時受限於最差性能的節點。

3. 節點數3到9個。同時一個節點故障不影響集群通信要求集群節點數為3。節點數越多，整體的性能下降越多，官方限制了節點數最大不超過9個。

4. InnoDB。MGR只支持事務性存儲引擎，InnoDB 5.7已經是默認存儲引擎

5. Primary key。驗證過程需要通過主鍵來檢測沖突，為innodb表指定主鍵也是InnoDB表的優化。

6. Performance Schema。集群狀態，節點性能等信息都會寫入這個schema的相應表中。

7. GTID。用於生成事務的全局唯一標識，以及恢復過程中確定延遲數據。

8. 應用感知提交失敗。驗證復制的機制決定了事務的提交會因為驗證失敗進行回滾，所以應用程序需要獲取事務的執行結構，並對失敗的事務做對應處理

限制

• 不支持binlog checksum

• 不支持savepoint

• 不支持gap locks

• 不支持lock tables, unlock tables

• 多主模式不支持多節點同時對一個表進行DDL vs DDL/DML

• 多主模式不支持SERIALIZABLE隔離級別

• 多主模式不支持多級關聯外鍵