組複製技術架構 | 深入淺出MGR

*   G r e a t S Q L 社 區 原 創 內 容 未 經 授 權 不 得 隨 意 使 用 ， 轉 載 請 聯 系 小 編 並 注 明 來 源 。

1. 傳統主從複製技術架構

傳統主從複製的方式是在master節點上執行資料更新事務，而後記錄這些事務到binlog中，再將binlog傳送到slave節點轉儲成relay log，在slave節點上再有單獨的執行緒讀取這些relay log然後重新執行或應用這些事務，它是shared-nothing的，每個節點都有一份完整的資料副本。

• 技術流程圖如下所示：

MySQL還提供了半同步複製，這是在傳統主從複製的基礎上增加了一個同步的步驟，master節點上提交事務前，要先等到slave節點確認收到事務資訊才可以（所以前文才說當slave節點響應慢時會影響master節點的事務提交）。

• 其技術流程圖如下所示：

2. MGR組複製技術架構

• MGR也是shared-nothing的，每個節點都有一份完整的資料副本，節點間通過GCS（Group Communication System）進行互動。GCS層提供了節點間的全域性訊息及其有序性的保證。

• MGR可以做到在任何節點、任何時間都能執行讀寫事務（不含只讀事務），不過讀寫事務要被整個複製組確認後才能提交。如果是隻讀事務則沒有這個限制，任何節點都可以發起及提交。

• 當讀寫事務準備提交前，它會向複製組發出一個原子廣播，內容包括：該事務修改的資料，及其所對應的writeset。複製組中所有節點要麼接收該事務，要麼都不接收。如果組中所有節點都接收該事務訊息，那麼它們都會按照與之前傳送事務的相同順序收到該廣播訊息。因此，所有組成員都以相同的順序接收事務的寫集，併為事務建立全域性順序。

• 在多個節點上並行執行的事務是可能產生衝突的，這時候就需要對比判斷兩個並行事務的writeset來確認，這個過程稱為事務認證，也叫做衝突檢測。事務衝突檢測是行級別的，也就是說兩個並行的事務更新同一行時，則視為產生衝突。這時的做法是全域性順序在前面的事務可以成功，所有節點都提交該事務。而全域性順序在後面的事務會失敗回滾，各節點會刪除該事務。這實際上是個分散式的誰先提交誰先贏得事務的規則。建議：如果經常發生節點間的事務衝突，那最好將這些事務放在同一個節點上執行，這樣它們在本地事務併發控制協調下可能都可以提交成功，而不至於由於MGR的衝突檢測而導致某個事務總是被回滾。

• 對於正在應用或外化的事務，MGR允許它們不一定按照原有順序執行，只要不破壞事務的一致性和有效性即可。MGR預設要求是最終一致性，也就是說當所有事務都應用完畢後，所有節點的資料是一致的。當流量巨大時，事務可能會被外化而導致順序輕微不一致。例如在多主模式下，一個本地事務在通過認證後會被立即外化，儘管此時可能還有個比這更早全域性順序的遠端事務還沒被應用，只要MGR的認證執行緒認為這個事務不會產生衝突即可。在單主模式下，在Primary節點上的本地併發事務，在不產生衝突的情況下，其提交和外化的順序可能和該事物的全域性事務順序有輕微不一致。在Secondary節點上，由於沒有寫事務，因此它們的事務順序和全域性事務順序是一致的。

• 下圖描述了MGR的組複製協議，可以看到和傳統主從複製（及半同步複製）的一些差異。為了簡單起見，圖中少了共識演算法和Paxos相關的資訊：

3. MGR的單主和多主模式

MGR支援單主或多主兩種模式。

• 在啟動時，通過設定選項 group_replication_single_primary_mode 來決定使用哪種模式，各節點中該值的設定要求一致。設定為 ON 時表示採用 單主模式，當設定為 OFF 時表示採用 多主模式。

• 在執行過程中，不能線上修改 group_replication_single_primary_mode 的值，但是從 MySQL 8.0.13 開始，可以通過呼叫 group_replication_switch_to_single_primary_mode() 和 group_replication_switch_to_multi_primary_mode() 這兩個udf線上修改執行模式，或者通過MySQL Shell修改。

• 在單主模式 下，有且只有一個（Primary）節點可以寫入資料，其餘（Secondary）節點都只能讀資料。而在多主模式 下，可以在任意節點上同時讀寫資料。

• MGR最多隻能支援9個節點，無論單主還是多主模式。

4. 節點管理

• MGR由一組節點構成，每個節點都有唯一的名字，以 UUID 的格式表現。節點可以動態加入或離開（也可能是被動被驅逐）MGR。

• MGR的組成員服務用於維護定義各活躍節點的資訊，這些活躍節點資訊也稱之為組檢視（view）。各節點的組檢視是一致的，這表示在給定時刻組中有哪些活躍成員。

• MGR各節點除了在事務提交時要保持一致外，也包括組檢視發生變化時也要達成一致。當有新節點加入，或現有節點離開時，都會觸發新的組檢視變更。

• 當有節點主動離開叢集時，它會觸發叢集自動重配置，剩下的節點會就新的組檢視達成一致。但若節點是因為網路異常或宕機等原因意外離開叢集時，則無法觸發自動重配置，這時候叢集故障檢測機制會在該節點離開一段時間後識別到這個狀態，併發出重配置組檢視的提議。重配置組檢視需要得到多數派成員的同意才行，當無法形成一致時，就無法實現自動重配置，需要人工介入處理。無法形成一致意見可能的原因有，剩下的節點數沒達到總結點數的一半以上，也就是無法形成多數派。

• 在節點被確認故障之前，或在重新配置組以刪除該故障節點前，允許該節點短暫離線，然後嘗試重新加入叢集。在這種情況下，該節點可能會丟失它以前的狀態（事務資料），如果此時其他節點向它傳送了包含崩潰前的訊息，則這就可能會導致資料不一致等問題。

• 為了解決這個問題，從MySQL 5.7.22開始，MGR會檢查具有相同地址+埠的節點再次以新身份加入叢集的情況，確認當前是否還有其舊身份存在。這時候其新身份不能加入，直到舊身份能從叢集中刪掉。注意：，選項 group_replication_member_expel_timeout 的作用是設定一個等待期，使得節點在被正式驅逐前有更多時間嘗試重新加回叢集，也就是說處於被懷疑狀態的節點，在超時之前還可嘗試重新加入叢集，再次作為活躍節點。當節點超過 group_replication_member_expel_timeout 閾值並被從叢集中驅逐時，或節點執行 STOP GROUP_REPLICATION 退出叢集，或因節點宕機等情況下，該節點必須以新身份重新加入叢集。

5. 故障檢測

• MGR自帶故障檢測機制，它能發現並報告哪個節點處於靜默狀態，達到一定條件後會認為這個節點已死。它是個分散式的故障檢測服務，提供了哪個節點處於（被懷疑）已死狀態的資訊。

• 當一個節點靜默（不主動發信息，也不回覆其他節點的資訊）時，可能會觸發被懷疑。當節點A在給定時間內還沒有收到節點B的訊息時，則發生訊息超時並引發懷疑。在這之後，叢集內其他成員如果一致同意（多數派達成一致）對該節點的懷疑是確定的話，則會判定該節點發生了故障。

• 如果某個節點因為網路故障和其他節點斷開連線了，那麼它可能也會懷疑其他節點發生了故障。但由於它不能形成多數派決議，因此這個懷疑是無效的，此時該節點無法執行任何讀寫事務，最多隻能執行只讀事務。

• 當網路不穩定時，隨意兩個節點間可能頻繁斷開和重連，理論上說可能會導致所有節點都會標記為驅逐，叢集會退出並需要重建。為了避免這種情況，從MySQL 8.0.20開始，GCS會跟蹤標記為驅逐的節點，並決定某個可疑節點是否還留在多數派節點中，這使得叢集中至少有一個節點而不會退出。當被驅逐節點正式被從叢集中移出時，GCS會刪掉被標記為驅逐的記錄，使得它後面還能重新加回。

6.容錯機制

• MGR是基於分散式的Paxos演算法實現，因此要求有多數派節點存活以保證投票。這就決定了在不影響系統整體可用性前提下，可容忍發生故障的節點數量。假設總節點數是n，可容忍發生故障的節點數是f，則它們的關係是：n = 2*f + 1。簡言之，容忍發生故障的節點數，不高於總節點數的一半。

下表展示了不同節點數的對應關係：

文 章 推 薦 ：

• M y S Q L 高 可 用 架 構 演 進 及 實 踐

• 技 術 分 享   |   l o a d   d a t a 導 致 主 鍵 丟 失 的 神 祕 問 題

• 故 障 分 析   |   l i n u x   磁 盤 i o 利 用 率 高 ， 分 析 的 正 確 姿 勢

• 萬 答 # 2 0 ， 索 引 下 推 如 何 進 行 數 據 過 濾

• 萬 答 # 1 8 ， M y S Q L 8 . 0   如 何 快 速 回 收 膨 脹 的 U N D O 表 空 間

關 於   G r e a t S Q L

微 信

Q Q