組複製簡介

資料強可靠性

組複製基於Paxos協議的多數派原則，確保資料可靠性。當多數派節點（指叢集中超過半數的節點）接收到事務的Binlog後，事務才會提交。這保證了在多數派可用的情況下，任何少數派節點（叢集中少於半數的節點）故障都不會導致資料丟失。

例如，5個節點的叢集，3個節點收到Binlog，2個節點未收到Binlog，此時有2個節點故障：

• 即使2個故障節點是收到Binlog的節點，至少還有1個節點有資料。

• 如果故障的2個節點是沒收到Binlog的節點，則至少有3個節點上有資料。

資料強一致性

組複製通過先傳輸事務到叢集其他節點再寫入Binlog的方式，確保主備節點資料一致性。舊主節點故障重啟後，會自動加入叢集並拉取缺失的Binlog，從而獲得最新資料。

傳統主備複製的問題：主節點在寫入Binlog後、傳輸到備節點前發生故障，可能導致主備資料不一致。

全域事務強一致性

組複製支援全域事務強一致讀和寫能力，並可通過group_replication_consistency參數調整一致性等級：

• 強一致讀： 在備節點設定group_replication_consistency=BEFORE，查詢時會等待主節點上所有先於該查詢的事務完成後再執行，確保主備資料一致。

• 強同步寫： 在主節點設定group_replication_consistency=AFTER，寫事務會在所有節點應用成功後才返回提交結果。

Paxos協議

Paxos協議在組複製中的作用包括：

• 確保叢集中各節點收到資料的順序一致，這是多主模式實現的基礎。

• 確保多數派收到資料後事務才能提交，提升資料可靠性。

在Paxos協議中，使用鎖的方式來實現節點間順序一致性，這種方式存在一定的效率問題，並且還存在著負載不均衡的問題。在工程實現過程中，MySQL的XCom層基於Mencius協議（Paxos變種協議），通過輪詢方式實現負載平衡，提升節點間效率。

多主模式實現原理

• 資料順序： 每個組內資料發送是串列的，保證單組內順序一致。多個組間通過輪詢機制確保全域順序，例如按 (1,1)、(1,2)、(1,3) 的順序發送資料。

• Noop機制： 如果某節點發現後續順序號已完成Paxos過程且自身無資料發送，則廣播Noop跳過該順序號。每個節點需等待前序節點發送資料或Noop後才能繼續。

• 缺陷： 當某節點故障或抖動時，既無法發送資料也無法發送Noop，導致後續節點無法發送資料，叢集可能完全不可用。這是多主模式的主要缺陷。

單主模式實現原理

上文中提到的多主模式的缺陷可以最佳化，但無法從根源上避免。為此MySQL推出了組複製的單主模式，來解決少數派故障對叢集可用性的影響。

上圖是單主模式的XCom架構，由於只有一個節點可寫，只需啟用一個Paxos組。接收方的XCom在輪詢資料時，會自動忽略其他Paxos組。這樣，只要多數派可用，Paxos就能正常發送資料，叢集的可用性不受影響。

在單主模式下，備節點不會發送交易資料，但有時需要發送一些叢集管理資訊。備節點在發送資料時，必須向主節點請求一個發送資訊的位置，如上圖中的<3, 1>，並使用這個位置向全叢集發送自己的資料。這種發送方式效率低、時延高，但由於叢集管理資訊發送的頻率很低，並不會對效能造成影響。

組複製層

組複製層負責向叢集發送、接收和回放事務，主節點和備節點的工作原理如下：

• 主節點： 事務進入提交階段時，其Binlog被發送到XCom層並傳遞給其他節點。多數派確認接收後，進行衝突檢測：

  • 檢測成功：寫入Binlog並提交事務。

  • 檢測失敗：復原事務。

• 備節點： 事務被多數派接收後，由XCom層傳遞至組複製層進行衝突檢測：

  • 檢測成功：寫入Relay Log並由Applier線程應用。

  • 檢測失敗：丟棄交易資料。

衝突檢測

• 情境

  組複製在以下兩種情境中需要進行衝突檢測：

  • 多主模式：所有寫操作都需要衝突檢測。

  • 單主模式：切主時，若新主節點在應用完舊主的 Relay Log 前執行寫事務，也需要衝突檢測。

• 原理

  衝突檢測基於資料行的主鍵雜湊值，採用行級檢測機制。每個節點維護一個事務認證資訊數組（雜湊數組），其結構如下：

  • Key：資料行的雜湊值。

  • Value：最近修改該行的事務GTID與源節點提交時的gtid_executed集合的並集。

  當事務準備提交時：

  • 源節點發送事務修改的資料及一個提交集合（標識當前事務提交前已完成的事務）。

  • 叢集內所有節點根據事務修改的相關行雜湊值，從認證資訊數組中讀取對應的值，合并產生依賴集合（標識當前事務提交前必須完成的事務）。

  在當前事務提交或寫入Relay Log前，需要將上述兩個集合進行比較：

  • 如果提交集合包含了依賴集合，衝突檢測成功，事務在源節點寫入Binlog並提交，在其他節點寫入Relay Log。

  • 如果 提交集合不包含依賴集合，衝突檢測失敗，事務在源節點復原，在其他節點丟棄Relay Log。

  清理機制：

  為節省記憶體空間，認證資訊數組會定期清理無用資料：

  • 當事務在所有節點上執行完畢後，其修改的行資料可從認證資訊數組中移除。

  • 組複製每60秒清理一次已執行事務的資料。