Group Replication Background（組複製技術原理）

建立容錯系統的最常見方法是使元件冗餘，換句話說，部分元件可以刪除，系統應該繼續按預期執行。這產生了一系列挑戰，將這種系統的複雜性提高到一個完全不同的水平。具體來說，複製的資料庫必須處理這樣的情況，即它們需要維護和管理幾個伺服器而不是一個。此外，由於多個伺服器組成了一個“組”的概念來相互協同工作，必須處理幾個其他經典分散式系統問題，諸如網路劃分或裂腦情況。

因此，最終的挑戰是將資料庫的邏輯和多個例項之間的資料複製，以一致和簡單的方式融合好。換句話說，使多個伺服器同意系統的狀態和系統經歷的每個改變的資料。這可以被概括為使所有伺服器在每個資料庫例項狀態轉換上達成一致，使得它們都作為一個單個數據庫能否正常執行或者它們最終收斂到相同狀態。意味著整個叢集下的每個節點需要作為一個（分散式）狀態機操作。

MySQL組複製提供分散式狀態機複製，在伺服器之間具有強協調。當資料庫伺服器是屬於同一組時，組複製機制可以自動協調它們。該組可以在具有自動選擇新主庫功能的單主模式下操作，這種情況下一個組只有主節點才可以做寫操作。或者，對於更高階的使用者，該組可以以多主模式部署，即多個節點都可以做寫操作，即使它們是同時發過來的寫請求。不過這種情況下，應用層會有部分額外的限制。

有一個內建的組成員服務稱為group membership service，用以確保在任何給定的時間點該組的可用性和一致性的檢視。各個節點可以脫離和加入該組，並相應地更新該檢視。有時，組成員可能會意外脫離組，在這種情況下，故障檢測機制會檢測到此情況，並通知組檢視已更改。以上這些都是自動的。
 

一個事務要提交時，必須通過檢視它在全域性事務序列中的順序，並在得到大多陣列成員同意的情況下按照該順序提交。決定提交或廢棄一個已經執行過的事務是由每個成員單獨完成的，但所有成員必須做出相同的決定。假設這種情況，存在一個存在網路分割槽，導致成員無法達成協議的分割，則系統將不會進行，直到此問題解決。因此，還有一個內建的，自動的，裂腦保護機制。

所有上述功能都由組通訊協議實現。它提供了故障檢測機制failure detection mechanism，組成員服務group membership service以及安全和完全有序的訊息傳遞。所有這些屬性是保證創建出來的系統在多個節點之間進行復制時的資料一致性的關鍵。該技術的核心是Paxos
 
演算法的實現，它充當群組通訊系統引擎。

ReplicationTechnologies（複製技術對比）

Primary-Secondary Replication（傳統主從複製）

傳統的MySQL複製提供了一種簡單的主 – 從複製架構。它有一個primary節點（master節點）和一個或多個secondary節點（slave節點）。主節點執行寫操作，然後將該寫操作稍後（因此非同步地）傳送到從節點，從節點重新執行該SQL（在基於語句的複製中）或應用該操作影響的結果行（在基於行的複製中）。它是一個shared-nothing系統，預設情況下所有節點都有一個完整的資料副本。

還有一個半同步複製，它向非同步複製協議新增一個同步步驟。這意味著主節點在提交時等待從節點ACK確認它已經接收到事務。只有這樣，主節點才恢復提交操作。

在上面的兩個圖片中，您可以看到經典非同步MySQL複製協議（以及它的半同步變體）的圖。藍色箭頭表示在資料節點之間交換的訊息或者在伺服器和客戶端應用之間交換的訊息。

Group Replication（組複製）

組複製是一種可用於實現容錯系統的技術。複製組是一個通過訊息傳遞相互互動的伺服器組。通訊層提供了很多保證，例如原子訊息和總訊息序號的傳遞。通過這些強大的特性，我們可以構建更高階的資料庫複製解決方案。

MySQL組複製構建在這些屬性和抽象之上，並實現多主複製協議的更新。實質上，複製組由多個數據庫例項組成，並且組中的每個例項都可以獨立地執行事務。但是所有讀寫（RW）事務只有在被組批准後才會提交。只讀（RO）事務不需要在組內協調，因此立即提交。換句話說，對於任何RW事務，組需要決定是否提交，因此提交操作不是來自始發伺服器的單向決定。準確地說，當事務準備好在始發伺服器上提交時，該始發伺服器原子地廣播寫入值（已改變的行）和對應的寫入集（已更新的行的唯一識別符號）。然後為該事務建立一個全域性總序號。最終，這意味著所有伺服器以相同的順序接收同一組事務。因此，所有伺服器以相同的順序應用相同的一組更改，因此它們在組內保持一致。

但是，在不同伺服器上併發執行的事務之間可能存在衝突。通過檢查兩個不同的併發事務的寫集合來檢測這樣的衝突，這個檢查過程稱為認證（certification）。如果在不同的伺服器上執行的兩個併發事務更新同一行，則會出現衝突。解析過程會這麼做，首先發起的事務在所有伺服器上提交，而後發起的事務將在源伺服器上回滾，並由組中的其他伺服器刪除。這實際上是一個分散式環境下“優先提交者贏”的規則。

最後，組複製是一種無共享複製方案（shared_nothing），即每個伺服器都有自己的整個資料副本。 上圖描述了MySQL組複製協議，並通過將其與MySQL複製（或甚至MySQL半同步複製）進行比較，您可以看到一些差異。注意，為了清楚起見，這個圖片中缺少一些基本的共識和Paxos相關資訊。

Group ReplicationUse Cases（組複製應用場景）

組複製使您能夠通過在一組伺服器中複製系統狀態來建立具有冗餘的容錯系統。因此，即使一些伺服器發生故障，只要它不是全部或大多數，雖然可能降低系統性能或可擴充套件性，但系統仍然可用。單一伺服器故障是隔離和獨立的。它們由group membership service跟蹤，它依賴於分散式故障檢測器，分散式故障檢測器能夠在任何節點成員自願地或由於意外停止而離開群組時發出訊號。分散式恢復過程能夠確保當有新節點加入組時，該節點會自動更新到最新。Multi-master特性確保即使在單個伺服器故障的情況下也不會阻止更新。因此，MySQL組複製保證資料庫服務持續可用。

不過需要重點理解，儘管組複製存在高可用，但連線到它的客戶端必須被重定向或故障轉移到不同的伺服器。這不是組複製嘗試解決的問題，而是聯結器，負載均衡器，路由器或一些其他中介軟體更適合處理這個問題。

總而言之，MySQL組複製提供了高可用性，高彈性，可靠的MySQL服務。

Examples of Use Case Scenarios（應用案例）

·彈性複製 - 需要非常流暢的複製基礎架構的環境，其中伺服器的數量必須動態增長或收縮，儘可能減少副作用。例如，雲的資料庫服務。

·高可用分片 - 分片是實現寫擴充套件的常用方法。使用MySQL組複製實現高可用性分片，其中每個分片對映到複製組。

·替代主從複製 - 在某些情況下，使用單一主節點可能使其成為單點爭用。在某些情況下，寫入整個組可能更具可擴充套件性。

·自動化系統 - 可以將MySQL組複製當做一個純粹的自動化複製系統

Group ReplicationDetails（組複製詳解）

Failure Detection（失敗檢測）

組複製提供了一種故障檢測機制，其能夠找到和報告哪些伺服器是沒有響應的，並假定其是死的。更深入地說，故障檢測器是提供關於哪些伺服器可能已死的資訊的分散式服務。後續如果組同意懷疑可能是真的，則由組來決定該伺服器確實已經失敗。這意味著組中的其餘成員進行協調決定排除給定成員。

伺服器無響應時觸發懷疑機制。當伺服器A在給定時間段內沒有從伺服器B接收訊息時，發生超時就會引起懷疑。

如果伺服器與組的其餘部分隔離，則它懷疑所有其他伺服器都失敗。由於無法與組達成協議（因為它無法獲得大多數成員認可），因此其懷疑沒有後果。當伺服器以此方式與組隔離時，它無法執行任何本地事務。

 Group Membership(組成員服務)

MySQL組複製依賴於組成員服務group membership service。這是內建的外掛。它定義哪些伺服器是線上的並參與在複製組中。線上伺服器列表通常稱為檢視view。因此，組中的每個伺服器具有一致的檢視，其是在給定時刻積極參與到組中的成員。

複製組的成員們不僅需要同意事務是否提交，而且也需要決定當前檢視。因此，如果伺服器同意新的伺服器成為組的一部分，則該組本身被重新配置以將該伺服器整合在其中，從而觸發檢視改變。相反的情況也發生，如果伺服器自願地離開組，則該組動態地重新佈置其配置，並且觸發檢視改變。

請注意，當成員自願離開時，它首先啟動動態組重新配置。這觸發一個過程，所有成員必須同意新的檢視（也就是新檢視中沒有該離開成員）。然而，如果成員不由自主地離開（例如它已意外停止或網路連線斷開），則故障檢測機制實現這一事實，並且提出該組的重新配置（新檢視沒有該離開成員）。如上所述，這需要來自組中大多數成員的同意。如果組不能夠達成一致（例如，以不存在大多數伺服器線上的方式進行分割槽），則系統不能動態地改變配置，從而阻止腦裂情況引起的多寫。最終，這意味著管理員需要介入並解決這個問題。

Fault-tolerance（容錯機制）

MySQL組複製構建在Paxos分散式演算法的實現上，以提供伺服器之間的分散式協調。因此，它需要大多數伺服器處於活動狀態以達到選舉條件，從而做出決定。這對系統可以容忍的故障數量有直接影響，一個組複製中成員數量設定（n）為n = 2×f + 1。

在實踐中，這意味著為了容忍一個故障，組必須有三個伺服器。因此，如果一個伺服器故障，仍然有兩個伺服器形成大多數（三分之二）並且允許系統自動地繼續執行。但是，如果第二個伺服器也異常失敗，則該組（剩下一個伺服器）阻塞，因為沒有多數可以做出決定。

以下是說明上述公式的小表。