11. MGR技術架構及資料同步、認證機制 | 深入淺出MGR

• GreatSQL社群原創内容未經授權不得随意使用，轉載請聯系小編并注明來源。
• GreatSQL是MySQL的國産分支版本，使用上與MySQL一緻。

本文簡單介紹下MGR的整體技術架構概況，事務同步過程，事務認證機制等關鍵知識點。

1. MGR架構

再來看一遍MGR的架構圖：

從上圖可知，MGR工作時，主要涉及到以下三層：

1. Server層：負責處理使用者請求，接收使用者事務，傳回結果等。
2. MGR處理層：接收來自Server層的事務請求，處理Paxos層傳回消息。
3. Paxos層：将所有消息進行全局排隊，然後發送給MGR處理層。

MGR是以Plugin（插件）的方式內建到MySQL中，可以簡單靈活部署，它在MySQL進行事務處理、Binlog傳輸和持久化等邏輯處理時，預埋了一些（Hook）鈎子，在鈎子上注冊函數處理MGR相關邏輯。

以使用者送出事務為例：

1. 使用者線程發出commit，請求送出事務，處在Server層。
2. Server層調用MGR處理層，将事務資訊通過Paxos層進行同步，使用者線程等待。
3. MGR處理層處理Paxos同步後的消息，喚醒使用者線程，傳回到Server層。

在上面的架構圖中，可以看到有以下幾個子產品：

1. Capture，負責跟蹤本節點的事務。
2. Applier，負責執行遠端事務（在其他節點産生的事務）。
3. Recovery，負責故障恢複時，選擇donor節點，catch up binlog等。
4. Replication Protocol Logics，消息封裝、接收XCom傳回的消息、發送本節點消息給XCom、事務認證（沖突檢測）等。
5. GCE，在GCS層具體實作XCom（XCom是eXtended COMmunications的縮寫，是Paxos協定在MySQL裡的具體實作，在有些文章中看到Paxos和XCom可以認為是同一個意思）。

MGR叢集由DB1、DB2、DB3三個節點構成，則對于DB1來說，DB2、DB3上産生的事務就是遠端事務，而DB1上産生的事務則是本地事務。

2. 事務資料同步、認證過程

使用者發起事務請求，在MGR層的簡化流程是下面這樣的：

1. 事務寫binlog前先進入到MGR層。
2. 将事務封裝後通過Paxos一緻性協定進行全局排序，發送給MGR各個節點。
3. 在各節點上進行認證該事務。
4. 認證通過後本地節點寫Binlog完成送出，認證失敗則復原事務。
5. 其他遠端節點上把該事務寫relay log，後續再并行回放。

P.S，事務認證過程也叫做沖突檢測，是同一個意思。

下圖展示了事務在MGR的流轉過程：

下面介紹MGR工作流程中的一些關鍵點。

2.1 事務處理合法性判斷

首先，需要先判斷該事務是否需要交由MGR處理以及MGR目前是否可以處理事務。

如果事務已經屬于group_replication_applier 或 group_replication_recovery channel，說明該事務已經被本節點或其他節點的MGR子產品處理過，無需再進入MGR層。

如果事務進入MGR層，就先初始化事務GTID資訊，這裡要分為兩種情況。通常，進入MGR的新事務還未産生GTID，表明該事務是在本節點第一次執行；另一種是已經有GTID，這說明該事務是通過主從複制通道進入MGR的，比如該節點同時是一個主從複制的Slave節點。對于第一種情況，會在完成事務認證（沖突檢測）後配置設定GTID。

2.2 事務消息中都包含哪些資訊

将待認證事務封裝到消息中，主要包含以下幾個資訊：

1. 事務節點的server_uuid。
2. 事務執行時節點的gtid_executed和事務快照版本号。
3. 執行事務的thread_id。
4. 事務gtid是否已經配置設定。
5. 事務修改的記錄集的主鍵清單writeset。

2.3 事務認證流程幾個關鍵點

事務在每個節點上都需要進行認證，不管是本地事務還是遠端事務。

事務在MGR中進行認證前，會先進行全局排序，形成共識（consensus）。事務全局排序時是基于round robin的方式配置設定到對應的消息輪次，是以即便是不同節點同時修改同一條記錄的事務，經過全局排序後，也就有了先後順序。

事務認證有幾個要點：

1. 不同節點同時更新同一行資料（根據主鍵判定）才有可能産生沖突。
2. 不同節點同時更新不同資料行時，不會産生沖突。
3. 目前還不支援DDL的沖突檢測。
4. 不同節點同時更新同一行（主鍵值相同）産生的事務，進行全局排序後，會得到不同的序号。

事務認證不是簡單的對比，會先判斷是否為本地事務（本節點産生的事務），事務是否已配置設定了gtid等多種情形分别進行不同的處理。

1. 将事務消息中的server_uuid和本地節點的server_uuid對比，以确定是否為本地事務。
2. 将事務消息中的gtid_executed和本地認證資料庫對比，判斷是否合法事務。
3. 從本地認證資料庫中擷取待認證事務更新的每個主鍵的版本資訊，與待認證事務的快照版本進行一一比對，隻有待認證事務的快照版本不是本地認證資料庫中對應主鍵版本的子集時，事務才能夠判定為認證通過。

2.4 事務認證資料庫清理

再來看下事務認證資料庫裡的資料什麼時候可以被清理，怎麼清理的，以及MGR裡經典的60s性能抖動問題。

• 什麼時候可以被清理，認證通過且已被各個節點都送出的事務可以被清理。先擷取叢集中各個節點的gtid_executed資訊并取交集，再将資料庫中每條主鍵記錄的版本跟該交集進行對比，若主鍵版本是該交集的子集，那麼後續事務的認證一定用不到該主鍵版本資訊，可以被安全清理掉。
• 如何清理，MGR的每個節點維護一個背景線程，該線程每隔60s（寫死，目前無法調整）清理事務，是以當待清理事務特别多的時候，可能會出現性能抖動問題（這個問題在GreatSQL中解決了，不複存在）。

從上述的清理機制可見，使用MGR時應該注意幾點：

• 多使用小事務，避免事務堵塞。當事務中包含大量記錄時，每60s的定時任務可能無法清理完畢，造成性能抖動。
• 流控機制是以事務為機關進行統計和限速的，有大事務時顯然不合理（GreatSQL中優化了流控算法，除了事務數，還考慮事務大小，以及主從節點的延遲情況，更為有效）。
• 不要在業務高峰期執行DDL。因為大表DDL時，也可能引發事務認證資料庫暴漲的問題。因為Online DDL期間DML的事務無法被清理，可能會把記憶體爆掉。

3. 多數派原則

不同于PXC要求所有節點都必須達成一緻，MGR采用多數派原則。也就是說，在一個MGR叢集裡，隻要達成多數派一緻（存活節點數超過一半），事務還是可以正常寫入的。此外，MGR最高可支援9個節點，是以不同節點數和最多可容忍故障節點數的關系如下表所示：

總節點數	多數派節點數	最大容忍故障節點數
1	1
2	2
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3
8	5	3
9	5	4

4. 啟用MGR的一些先決條件

想要啟用MGR，需要先滿足幾個先決條件：

1. 每個節點都必須啟用binlog，而且使用row格式。
2. 每個節點都要啟用binlog轉儲，即

   log_slave_updates=1

   或

   log_replica_updates=1

   。
3. 每個節點的

   server_id

   及

   server_uuid

   不能相同。
4. 在8.0.20之前，要求

   binlog_checksum=NONE

   ，但是從8.0.20後，可以設定

   binlog_checksum=CRC32

   。
5. 要求啟用 GTID，即設定

   gtid_mode=ON

   。
6. 要求

   master_info_repository=TABLE

   及

   relay_log_info_repository=TABLE

   ，不過從MySQL 8.0.23開始，這兩個選項已經預設設定TABLE，是以無需再單獨設定。
7. 所有節點上的表名大小寫參數

   lower_case_table_names

   設定要求一緻。
8. 隻支援InnoDB表，其餘表雖然也能建立，但無法同步資料（Primary節點上寫入資料時會報錯）。
9. 必須要有主鍵，如果沒有主鍵（或者可以被選中作為聚集索引的輔助索引），則寫入資料時會報錯。
10. 建議啟用writeset模式，即設定以下幾個參數

    • slave_parallel_type = LOGICAL_CLOCK

    • slave_parallel_workers = N

      ，N>0，可以設定為邏輯CPU數的2倍

    • binlog_transaction_dependency_tracking = WRITESET

    • slave_preserve_commit_order = 1

    • slave_checkpoint_period = 2

5. 小結

本文介紹了MGR的整體技術架構概況，事務同步過程，事務認證機制等内容，使用MGR時需要注意的一些限制條件以及關鍵點。

參考資料、文檔

MySQL 8.0 Reference Manual

https://dev.mysql.com/doc/refman/8.0/en/group-replication.html

資料庫核心開發 - 溫正湖

https://www.zhihu.com/column/c_206071340

Group Replication原理 - 宋利兵

https://mp.weixin.qq.com/s/LFJtdpISVi45qv9Wksv19Q

深入淺出MGR專欄

01.MGR簡介

02.組複制技術架構

03.安裝部署MGR叢集

04.利用MySQL Shell安裝部署MGR叢集

05.MGR管理維護

06.MGR狀态監控

07.利用MySQL Router建構讀寫分離MGR叢集

08.利用Ansible快速建構MGR

09.利用Docker快速建構MGR

1. 選主算法、多版本相容性及滾動更新

免責聲明