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。
在實踐中，這意味着爲了容忍一個故障，組必須有三個服務器。因此，如果一個服務器故障，仍然有兩個服務器形成大多數（三分之二）並且允許系統自動地繼續運行。但是，如果第二個服務器也異常失敗，則該組（剩下一個服務器）阻塞，因爲沒有多數可以做出決定。
以下是說明上述公式的小表。
|
Group Size |
Majority |
Instant Failures Tolerated |
|
1 |
1 |
0 |
|
2 |
2 |
0 |
|
3 |
2 |
1 |
|
4 |
3 |
1 |
|
5 |
3 |
2 |
|
6 |
4 |
2 |
|
7 |
4 |
3 |