MySQL Group Replication調研剖析-組複製的工做原理及程序結構

這是我參與8月更文挑戰的第7天，活動詳情查看：8月更文挑戰

咱們前面提到了MySQL複製的三種模式，接下來咱們聊一下組複製的工做原理和程序結構。

組複製的工做原理

MySQL組複製是一個MySQL插件，它創建在現有的MySQL複製基礎結構上，利用了二進制日誌，基於行的日誌記錄和全局事務標識符等功能。它集成了當前的MySQL框架，如性能模式、插件和服務基礎設施等。

組複製（Group Replication）基於分佈式一致性算法(Paxos協議的變體)實現，一個組容許部分節點掛掉，只要保證絕大多數節點仍然存活而且之間的通信是沒有問題的，那麼這個組對外仍然可以提供服務，它是一種被使用在容錯系統中的技術。\

Group Replication（複製組）是由可以相互通訊的多個服務器（節點）組成的。 在通訊層，Group replication實現了一系列的機制：好比原子消息（atomic message delivery）和全序化消息（total ordering of messages）。這些原子化，抽象化的機制，爲實現更先進的數據庫複製方案提供了強有力的支持。
MySQL Group Replication正是基於這些技術和概念，實現了一種多主全更新的複製協議。
簡而言之，一個Group Replication就是一組節點，每一個節點均可以獨立執行事務，而讀寫事務則會在於group內的其餘節點進行協調以後再commit。所以，當一個事務準備提交時，會自動在group內進行原子性的廣播，告知其餘節點變動了什麼內容/執行了什麼事務。
這種原子廣播的方式，使得這個事務在每個節點上都保持着一樣順序。這意味着每個節點都以一樣的順序，接收到了一樣的事務日誌，因此每個節點以一樣的順序重演了這些事務日誌，最終整個group保持了徹底一致的狀態。然而，不一樣的節點上執行的事務之間有可能存在資源爭用。
這種現象容易出如今兩個不一樣的併發事務上。假設在不一樣的節點上有兩個併發事務，更新了同一行數據，那麼就會發生資源爭用。面對這種狀況，Group Replication斷定先提交的事務爲有效事務，會在整個group裏面重放，後提交的事務會直接中斷，或者回滾，最後丟棄掉。所以，這也是一個無共享的複製方案，每個節點都保存了完整的數據副本。\

從其工做的原理能夠看出，Group Replication基於Paxos協議的一致性算法校驗事務執行是否有衝突，而後順序執行事務，達到最終的數據一致性，也就意味着部分節點能夠存在延遲。能夠設置多主同時寫入和單主寫入，經過設置group_replication_single_primary_mode來進行控制是多主仍是單主，官方推薦單主寫入，容許延遲，但延遲過大，則會觸發限流規則（可配置的），整個集羣會變的很慢，性能大打折扣。

組複製的程序結構

在MySQL的底層，GR增長了另外的API層來實現所須要的功能。程序結構上，GRAPI主要分爲三部分：

• 1:capture 追蹤當前正在執行的事務的上下文。、

• 2:applier 執行遠程事務傳輸到本地的日誌到本地數據庫。、

• 3:recovery 負責分佈式環境下的節點恢復，以及相關的數據回追，失敗處理等。

  在這幾個主要API層的下面，是統一的複製協議邏輯處理層，這一層主要是統一應用層的各類調用。在更下層，則是通用程度更高的分佈式通信層，處於調用便利，分佈式通信曾對上提供使用的API，API的下面，是Paxos實現的分佈式通信協議組件，這個組件與集羣中其餘節點一塊兒，造成一個虛擬概念化的分佈式集羣。