原文：https://dev.mysql.com/doc/refman/8.0/en/group-replication-background.html
譯者：kun
最近在翻譯MySQL8.0官方文檔 第18章組複製部分，分享出來大家讀讀，有想加入翻譯小隊的同學可以聯繫我哦。
本節介紹有關MySQL組複製的背景信息。
創建容錯系統的最常見方法是創建組件冗餘，換句話說，組件可以被移除，而系統應該繼續按預期運行。這就造成了一系列的挑戰，將這種系統的複雜性提高到一個完全不同的水平。具體而言，複製的數據庫需要同時維護和管理若干個server成員，而不只是一個。此外，當多個server協同工作是，系統必須處理其他一些常見的分佈式系統問題，諸如斷網或腦裂等情況。
因此，最大的挑戰是將數據庫和數據複製的邏輯與若干個server以簡單一致的方式協調運行的邏輯相融合。換句話說，也就是使多個server成員關於系統的狀態和系統每次變更的數據保持一致。這可以被概括爲使多個server對於每個數據庫狀態轉換達成共識，從而使它們都作爲一個獨立的數據庫運行，或者說它們最終達到相同狀態。這就意味着它們需要作爲（分佈式）state machine運行。
MySQL Group Replication提供了一種強大的server間協調機制的分佈式state machine複製。組中的server成員會自動地進行協調。在單主模式下，組複製具有自動選主功能，每次只有一個服務器成員接受更新。在多主模式下運行時，所有的服務器成員都可以同時接受更新。這種功能就要求應用程序不得不解決部署所帶來的限制。
有一個內置的組成員服務，用於保持組視圖的一致性，並在任何給定的時間點對於所有server可用。當Server離開或加入組時，視圖會相應地進行更新。server也可能會意外離開組，故障檢測機制會自動檢測到此情況，並通知組該視圖已更改。
對於要提交的事務，決定提交或中止事務是由每個server單獨完成的，但所有組成員必須就該事務在全局事務序列中的順序達成一致意見。如果存在網絡分隔，造成組成員間無法達成協議，則系統在此問題解決前將不會繼續運行。因此，組複製還內置了一個自動的腦裂保護機制。
這種機制都是由系統提供的組通信協議（GCS）提供支持的。該協議保障了故障檢測機制，組成員服務的安全和消息的完全有序傳遞。該技術的核心是Paxos算法實現的，是組複製中保證數據一致性複製的關鍵， 它充當了組通信系統的引擎。
18.1.1 複製技術
在介紹MySQL組複製的詳細信息之前，本節將簡要介紹一些背景概念以及組複製是如何運行的。通過本節我們可以瞭解組複製中需要什麼，以及傳統異步MySQL複製和組複製之間的區別。
18.1.1.1 主-從複製
傳統的MySQL複製提供了一種簡單的主–從複製方法。有一個主，以及一個或多個從。主節點執行和提交事務，然後將它們（異步地）發送到從節點，以重新執行（在基於語句的複製中）或應用（在基於行的複製中）。這是一個shared-nothing的系統，默認情況下所有server成員都有一個完整的數據副本。
圖18.1 MySQL異步複製
還有一個半同步複製，它在協議中添加了一個同步步驟。這意味着主節點在提交時需要等待從節點確認它已經接收到事務。只有這樣，主節點才能繼續提交操作。
圖18.2 MySQL半同步複製
在上面的兩個圖片中，可以看到傳統異步MySQL複製協議（以及半同步）的圖形展示。藍色箭頭表示在不同server之間或者server與client應用之間的信息交互。
18.1.1.2 組複製
組複製是一種可用於實現容錯系統的技術。複製組是一個通過消息傳遞相互交互的server集羣。通信層提供了原子消息（atomic message）和完全有序信息交互等保障機制。這些是非常強大的功能，我們可以據此架構設計更高級的數據庫複製解決方案。
MySQL組複製以這些功能和架構爲基礎，實現了基於複製協議的多主更新。複製組由多個server成員構成，並且組中的每個server成員可以獨立地執行事務。但所有讀寫（RW）事務只有在衝突檢測成功後纔會提交。只讀（RO）事務不需要在衝突檢測，可以立即提交。換句話說，對於任何RW事務，提交操作並不是由始發server單向決定的，而是由組來決定是否提交。準確地說，在始發server上，當事務準備好提交時，該server會廣播寫入值（已改變的行）和對應的寫入集（已更新的行的唯一標識符）。然後會爲該事務建立一個全局的順序。最終，這意味着所有server成員以相同的順序接收同一組事務。因此，所有server成員以相同的順序應用相同的更改，以確保組內一致。
在不同server上併發執行的事務可能存在衝突。根據組複製的衝突檢測機制，對兩個不同的併發事務的寫集合進行檢測。如在不同的server成員執行兩個更新同一行的併發事務，則會出現衝突。排在最前面的事務可以在所有server成員上提交，第二個事務在源server上回滾，並在組中的其他server上刪除。這就是分佈式的先提交當選規則。
圖18.3 MySQL組複製協議
最後，組複製是一種share-nothing複製方案，其中每個server成員都有自己的完整數據副本。
上圖描述了MySQL組複製協議，並通過將其與MySQL複製（MySQL半同步複製）進行比較，可以看到一些差異。需要注意的是，這個圖片中不包含一些基本共識和Paxos相關的信息。
18.1.2 組複製用例
組複製使您能夠根據在一組server中複製系統的狀態來創建具有冗餘的容錯系統。因此，只要它不是全部或多數server發生故障，即使有一些server故障，系統仍然可用，最多隻是性能和可伸縮性降低，但它仍然可用。server故障是孤立並且獨立的。它們由組成員服務來監控，組成員服務依賴於分佈式故障檢測系統，其能夠在任何server自願地或由於意外停止而離開組時發出信號。他們是由一個分佈式恢復程序來確保當有server加入組時，它們會自動更新組信息到最新。並且多主更新確保了即使在單個服務器故障的情況下也不會阻止更新，不必進行server故障轉移。因此，MySQL組複製保證數據庫服務持續可用。
值得注意的一點是，儘管數據庫服務可用，但當有一個server崩潰時，連接到它的客戶端必須重定向或故障轉移到不同的server。這不是組複製要解決的問題。連接器，負載均衡器，路由器或其他形式的中間件更適合處理這個問題。
總之，MySQL組複製提供了高可用性，高彈性，可靠的MySQL服務。
18.1.2.1 用例場景示例
以下示例是組複製的典型用例。
-
彈性複製 - 需要非常流暢的複製基礎架構環境，其中server的數量必須動態增長或收縮，並儘可能減少副作用。例如，雲數據庫服務。
-
高可用分片 -分片是實現寫擴展的常用方法。使用MySQL組複製實現高可用性分片，其中每個分片映射到一個複製組。
-
替代主從複製- 在某些情況下，使用單個主服務器會造成單點爭用，寫入整個組可能更具可擴展性。
-
自動系統 -此外，您可以將MySQL組複製直接部署到已有複製協議的自動化系統中（在本章和前面的章節中已經描述過）。
18.1.3 組複製詳細信息
本節介紹有關組複製基礎服務的詳細信息。
18.1.3.1 故障檢測
組複製提供了一種故障檢測機制，它能夠找到並報告哪些server成員是無響應的，並且假定這些server已死。在更高級別來說，故障檢測是提供關於哪些server可能已死的信息（猜測）的分佈式服務。然後，如果組同意該猜測可能是真的，則組判定給定的server確實已經failed。這意味着組中的其餘成員進行協調決定以排除給定成員。
某個server無響應時觸發猜測， 當server A在給定時間段內沒有從server B接收消息時，將會發生超時並且觸發猜測。
如果某個server與組的其餘成員隔離，則它會懷疑所有其他server都失敗了。由於無法與組達成協議（因爲它無法確保仲裁成員數），其懷疑不會產生後果。當服務器以此方式與組隔離時，它無法執行任何本地事務。
18.1.3.2 組成員關係
MySQL組複製依賴於組成員服務。這是一個內置的插件。它定義了哪些server在線並在組中。在線server列表通常稱爲視圖。因此，組中的每個server對於給定時刻積極參與組中的成員具有一致的視圖。
同組server不僅需要關於事務提交必須達成一致意見，關於當前視圖也是。因此，如果同組server同意新的server加入，則該組本身將被重新配置從而將該server加入其中，並觸發視圖更新。相反，如果server離開組，無論自願或被迫的情況，該組都會動態地重新規劃其配置，並觸發視圖更新。
要注意的是，當成員自願離開時，它首先啓動組的動態重新配置。這觸發一個過程，其中所有成員必須就不包含已離開server的新視圖達成一致。然而，如果成員由於發生意外而離開（例如它意外停止或網絡連接斷開），則故障檢測機制檢測到後，將提出該組的重新配置，去除故障成員。如上所述，這需要來自組中大多數服務器達成一致意見。如果組不能夠達成一致（例如，當大多數服務器都不在線的情況），則系統不能動態地改變配置，而且系統會鎖定以防止腦裂情況的發生。最終，這意味着管理員需要介入並解決這個問題。
18.1.3.3 容錯
MySQL組複製構建在Paxos分佈式算法實現的基礎上，以提供不同server之間的分佈式協調。因此，它需要大多數server處於活動狀態以達到仲裁成員數，從而做出決定。這對系統可以容忍的不影響其自身及其整體功能的故障數量有直接影響。容忍f個故障所需的server數量（n）爲n = 2×f + 1。
在實踐中，這意味着爲了容忍一個故障，組必須有三個server。因此，如果一個服務器故障，仍然有兩個服務器形成大多數（三分之二）來允許系統自動地繼續運行。但是，如果第二個server意外地fail掉，則該組（剩下一個server）鎖定，因爲沒有多數可以達成決議。
以下是說明上述公式的小表。
| 組大小 | 多數 | 允許的即時故障數 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
下一章將涵蓋組複製技術方面的知識。
