作者：宋利兵

來源：MySQL程式碼研究(mysqlcode)

以下是我在DTCC大會上的分享的《深入理解MySQL Group Replication》的核心內容Group Replication架構原理的PPT，分享給大家。

上圖是狀態機複製的簡單原理，其實MySQL的非同步複製也是狀態機複製。

Group Replication使用了原子廣播系統的原理：

• 每個節點上有一個廣播模組。

• 每個廣播模組都能接收使用者的請求。

• 廣播模組之間進行通訊，對請求進行全域性排序。最終每個節點的廣播模組上都會有一個順序完全一樣的請求佇列。

• 廣播模組將佇列中的請求按照順序傳送給DB執行，符合狀態機複製的要求（按照同樣的順序執行同樣的操作）。因此所有DB的資料保持一致。
  

Group Replication在實現上有一些變化，但原理是一樣的。Group Replication廣播的不是原始事務語句而是事務的Binlog Events。因此廣播模組是嵌在事務執行流程中的，而不需要和客戶端互動。當事務語句執行完準備提交時，Group Replication會捕捉到事務的Binlog Events然後進行原子廣播。先執行，再全域性排序的方法會導致衝突。即當前事務排在另一個修改了同一行資料的事務的後面，但是執行卻在前面。因此需要做衝突檢測。

本地事務和遠端事務的執行流程不一樣，因此分別介紹。

事務在每個節點上都需要在Certify模組進行衝突檢測，不管是本地事務還是遠端事務。衝突檢測的過程是在每個模組上單獨進行的，不需要在各個節點之間互動。這裡其實是應用了狀態機複製的原理，所有節點上的事務都是按照同樣的順序做的衝突檢測。因此任何一個事務在所有節點上的衝突檢測結果都是相同的。

• 如果事務在一個節點上認證成功了，那麼在其他節點上肯定也是成功的。

• 如果事務在一個節點上認證失敗了，那麼在其他節點上肯定也是失敗的。
  

衝突檢測有兩個因素：

1. 事務是否修改了同樣的資料（以行為單位，通過主鍵識別）。

2. 是否是同時修改的。通過事務執行時的資料庫快照版本來判定。資料庫的快照是用GTID SET來標識的。事務提交前從全域性變數gtid_executed中獲取GTID SET。這個GTID SET就是代表了當前事務在提交前，資料庫中已經執行了的GTIDs。也即是當前事務提交前，資料庫的快照版本。資料庫的快照版本會隨著事務的Binlog Events一起廣播到其他的節點上，用來做衝突檢測。
   

由於時間原因，以下部分未能在DTCC上分享給大家。這裡一併分享給大家。

衝突檢測資料庫中記錄了已經通過認證的事務所修改的主鍵和一個GTID SET。

衝突檢測時，從衝突檢測資料庫中找到當前事務修改的資料的記錄。如果沒有找到，就沒有衝突。如果找到了，則將自己的快照版本和衝突檢測資料庫中記錄的GTID SET進行比對：

• 如果自己的快照版本中包含了衝突檢測資料庫中記錄的所有GTIDs，那麼就沒有衝突。自己的快照中包含了，說明該事務在初始節點上執行時，上一次對本行資料的修改已經在初始節點上提交了。所以就不是同時執行的。

• 如果自己的快照版本中沒有包含衝突檢測資料庫中記錄的所有GTIDs，則說明當前事務在初始節點上執行時，上一次對本行資料的修改還沒有在初始節點上執行。因此判定為同時執行。
  

認證成功後，要更新衝突檢測資料庫。更新後的GTID SET是當前事務的快照版本+當前事務的GTID。

認證失敗，不需要更新衝突檢測資料庫。

推薦訂閱原文作者 宋利兵 的公眾號 MySQL程式碼研究