目錄
3. 數據操作語言（Data Manipulation Language，DML）
4. 數據定義語句（Data Definition Language，DDL ）
MySQL Group Replication（MGR）是MySQL 5.7.17版本引入的一個服務器插件，可用於創建高可用、可擴展、容錯的複製拓撲結構。組複製可以在單主模式下操作，其中只有一個服務器接受更新，這個單主是系統自動選舉出來的。對於高級用戶，也可以部署爲多主模式，其中所有服務器都可以接受更新。內置的組成員服務可以在任何給定的時間點保持組的視圖一致並可供所有服務器使用。當服務器加入或離開組時，視圖也會相應更新。當服務器宕機，故障檢測機制會檢測到此情況並通知組其視圖已更改。這些都是自動進行的。
創建容錯系統最常見的方法是組件冗餘。換句話說，一個組件被移除時，系統應該繼續按預期運行。這產生了一系列挑戰，將這種系統的複雜性提高到了一個完全不同的水平。數據複製必須維護和管理多個服務器，還必須處理若干其它經典的分佈式系統問題，如網絡分區或腦裂。對MySQL而言，最終的挑戰是將數據複製邏輯與協調多個服務器的邏輯相融合。這可以概括爲讓每個服務器的狀態在數據變化時達成一致，即便它們都作爲單個數據庫系統運行，但最終都收斂到相同的狀態。
MGR對屬於同一組的服務器自動進行協調。對於要提交的事務，組成員必須就全局事務序列中給定事務的順序達成一致。提交或回滾事務由每個服務器單獨完成，但所有服務器都必須做出相同的決定。如果存在網絡分區，導致成員無法達成事先定義的分割策略，則在解決此問題之前系統不會繼續進行，這是一種內置的自動裂腦保護機制。MGR由組通信系統（Group Communication System，GCS）協議支持。該系統提供故障檢測機制、組成員服務以及安全且有序的消息傳遞。所有這些屬性都是創建系統的關鍵，可確保在服務器組中一致地複製數據。該技術的核心是Paxos算法的實現，它充當組通信引擎。
一、MySQL複製技術
在深入瞭解MySQL組複製的細節之前，先介紹一些其產生的背景以及工作原理，以幫助理解組複製，以及傳統異步複製、半同步複製和組複製之間的區別。
1. 主從複製
傳統的MySQL複製提供了一種簡單的主從複製方法。有一個主庫，一個或多個從庫。主庫執行並提交事務，然後通過二進制日誌將事務相關的事件異步發送到從庫，以便重放。這是一個無共享系統，默認情況下所有服務器都擁有完整的數據副本。
半同步複製爲異步複製協議添加了一個同步步驟。這意味着主庫在提交時等待至少一個從庫確認它已收到該事務，纔會繼續提交操作。
圖1圖2分別表示MySQL異步複製協議以及它的半同步變體。對角箭頭表示服務器之間交換的消息或服務器與客戶端應用程序之間交換的消息。
2. 組複製
組由多個服務器構成，通過傳遞消息進行交互，通信層保證原子消息傳遞。MGR構建於此通信層抽象之上，並實現了多主更新複製協議。組中的每個服務器獨立地執行事務，但是所有讀寫事務只有在得到組的批准後纔會提交。只讀事務在組內不需要協調，因此立即提交。對於任何讀寫事務，當事務準備好在始發服務器處提交時，服務器以原子方式廣播寫入值（更改的行）和對應的寫入集（更新的行的唯一標識符），然後將該事務加入全局事務列表。最終所有服務器都以相同的順序接收並應用相同的事務集，所以它們在組內保持一致。
不同服務器上併發執行的事務之間可能存在衝突。MGR在certify過程中檢查併發事務的寫集來檢測這種衝突。如果在不同服務器上執行的兩個併發事務更新同一行，則存在衝突。解決方案是先到事務提交，後到事務回滾，即按順序第一個事務在所有服務器提交，而第二個事務在在原始服務器上回滾並在組中的其它服務器中刪除。這實際上體現的是多主分佈式事務的首個提交獲勝原則。
圖3描述了MGR協議。組複製同樣是一種無共享複製方案，其中每個服務器都有自己的整個數據副本。
二、組複製使用場景
組複製可用來創建具有冗餘的容錯系統。即使某些服務器發生故障，只要它不是全部或大多數，系統仍然可用。根據失敗的服務器數量，可能會降低性能或可伸縮性，但它仍然可用。組成員服務跟蹤服務器故障，該服務依賴於分佈式故障檢測器，能夠在任何服務器脫離組時發出信號，無論是意外停止還是主動停止。分佈式恢復過程確保當服務器加入組時能自動更新。單個服務器發生故障時不會停止服務，也無需服務器故障轉移。總之，MGR保證數據庫服務持續可用。
需要注意，儘管數據庫服務可用，但在服務器崩潰的情況下，必須將連接到它的客戶端重定向或轉移到其它服務器。組複製不解決數據庫連接重定向的問題，連接器、負載平衡器、路由器或某種形式的中間件更適合處理此問題，例如MySQL Router。
以下是組複製的典型使用場景。
- 彈性複製：服務器的數量能夠動態增加或減少，並且儘可能減小副作用，例如雲數據庫服務。
- 高可用分片：分片是實現寫擴展的流行方法。使用MGR實現高可用分片，其中每個分片映射到複製組。
- 主從複製的替代方案：在某些情況下，使用單個主服務器會使其成爲熱點，寫入整個組會更具可擴展性。
三、組複製相關服務
1. 故障檢測
組複製包括一種故障檢測機制，該機制能夠查找並報告哪些服務器已經宕機。當服務器A在給定時間內沒有從服務器B接收到消息時，發生超時並引發懷疑。然後如果組同意懷疑是真的，那麼該組決定給定服務器確實宕機了。這意味着該組中的其餘成員將採取協調決策以排除給定成員。
如果一個服務器與組的其餘部分隔離，它會懷疑所有其它服務器都已失敗，但由於無法與該組達成協議（因爲無法確保法定票數），其懷疑並沒有結果。當服務器以這種方式與組隔離時，它無法執行任何本地事務。
2. 組成員服務
MGR依賴於組成員服務，該服務內置於插件中。它定義了哪些服務器在線並參與該組。在線服務器列表通常稱爲視圖。因此，組中的每個服務器都具有一致的視圖，其中是在給定時刻主動參與該組的成員。
服務器不僅必須同意事務提交，還要同意當前視圖。因此，如果服務器同意新服務器成爲組的一部分，則組本身將重新配置爲將該服務器集成在其中，從而觸發視圖更改。相反的情況也會發生，如果服務器離開組，則組會動態更新配置並觸發視圖更改。
組成員離開組分主動與被動。主動離開會啓動組的動態重新配置，這會觸發所有其它成員必須在沒有該服務器的情況下就新視圖達成一致。被動離開（如已意外停止或斷網）時，故障檢測機制會建議重新配置組，這需要組中大多數服務器的同意。如果該組無法達成協議，爲阻止腦裂，系統無法動態更改配置，這意味着管理員需要介入解決此問題。
3. 容錯
MGR構建於Paxos分佈式算法的實現之上，需要多數服務器處於活動狀態才能達到法定票數，從而做出決定。這直接影響系統可以容忍的故障機數量，但不會影響組複製自身及其整體功能。容忍 f 個故障機所需的服務器數量 n 爲：n = 2 * f + 1。
實踐中爲了容忍一個故障機，該組必須具有三個服務器，因爲此時如果一個服務器發生故障，仍然有兩個服務器構成多數，並允許系統繼續自動做出決策並繼續提供服務。但如果第二個服務器繼續失敗，那麼該組（剩下一個服務器）會阻塞，因爲沒有多數票可以做出決定。
四、組複製技術細節
1. 組複製插件體系結構
MGR是一個MySQL插件，它以現有的MySQL複製架構爲基礎，利用二進制日誌、基於行的日誌記錄和全局事務標識符（GTID）等功能。圖4顯示了MGR插件架構。
MGR插件包含一組捕獲、應用和生命週期API，用於控制插件與MySQL服務器的交互方式。這些接口將MySQL服務器核心與MGR插件隔離。服務器向插件通知啓動、恢復、準備接收連接、即將提交事務等消息。插件指示服務器執行諸如提交事務、中止正在進行的事務、事務在中繼日誌中排隊等動作。
組複製插件體系結構的下一層是一組組件。捕獲組件負責跟蹤與正在執行的事務相關的上下文。應用組件負責在數據庫上執行遠程事務。恢復組件管理分佈式恢復，負責選擇捐贈者，對故障做出反應，執行追趕程序，使加入該組的服務器獲得更新。
堆棧下一層的複製協議模塊包含複製協議的特定邏輯。它處理衝突檢測，接收事務並將其傳播到組。
組複製插件體系結構的最後兩層是組通信系統（GCS）API，以及基於Paxos的組通信引擎（XCom）的實現。GCS API將消息傳遞層的實現與插件上層分離，組通信引擎處理與複製組成員的通信。
2. 複製組
MGR中的一組服務器構成一個複製組，組名形式爲UUID。組是動態的，服務器可以離開（主動或被動）並隨時加入組。服務器加入或離開時，組會自行調整。如果服務器加入組，組會通過從現有服務器獲取狀態自動更新新加入的服務器。狀態通過MySQL異步複製進行傳輸。如果服務器離開該組，其餘服務器會知道它已離開並自動重新配置該組。
3. 數據操作語言（Data Manipulation Language，DML）
組中的每個服務器都被允許隨時執行讀寫事務。任何服務器都可以在沒有任何事先協調的情況下執行事務。但在提交時，它與組中的其餘服務器協調，以便就該事務的操作做出決定。這種協調有兩個目的：一是檢查事務是否可以提交；二是傳播更新，以便其它服務器也可以應用該事務。
當事務通過原子廣播發送時，組中的所有服務器都接收該事務，或者都不接收該事務。它們會以與之前發送的其它事務相同的順序收到它，並通過檢查和比較寫入事務集來執行衝突檢測。衝突解決遵循首個提交者獲勝規則。例如，事務t1和t2在不同的站點同時執行，t2排在t1之前，並且兩者都改變了同一行，那麼t2贏得衝突被執行，t1被中止。如果兩個事務經常發生衝突，最好在同一臺服務器上啓動它們，這樣它們有機會在本地鎖管理機制下並行執行，而不是稍後在複製協議中中止。
4. 數據定義語句（Data Definition Language，DDL ）
在組複製拓撲中，執行數據定義語句時需要小心。MySQL 8.0 引入了對原子數據定義語言的支持，其中完整的DDL語句作爲單個原子事務提交或回滾。但是，原子或其它DDL語句隱式結束當前會話中處於活動狀態的任何事務，就好像在執行語句之前已完成COMMIT一樣。這意味着DDL語句自成事務，不能在另一個事務中，或在START TRANSACTION ... COMMIT等事務控制語句中，或者與同一事務中的其它語句結合使用。
組複製基於樂觀複製，其中語句被樂觀執行（執行時不事先鎖定對象）並在稍後必要時回滾。每個服務器首先執行和提交而不保護組協議。因此，在多主模式下複製DDL語句時需要更加小心。如果對同一對象進行結構更改（使用DDL）並更改對象包含的數據（使用DML），則需要通過同一服務器處理更改。如果不這樣做，可能會因操作中斷或部分完成，導致數據不一致。如果組以單主模式部署，則不會發生此問題，因爲所有更改都是通過同一服務器（主服務器）執行的。
5. 分佈式恢復
（1）分佈式恢復基礎
組複製分佈式恢復可以概括爲服務器從組中獲得丟失事務的過程，以便它可以加入具有已處理相同事務集成員的組。在分佈式恢復期間，加入組的服務器會緩衝其正在接收的，組中所需的事務和成員事件。一旦加入該組的服務器收到了該組的所有事務，它就會應用在恢復過程中緩衝的事務。此過程結束時，服務器隨之作爲在線成員加入組。
分佈式恢復分爲兩個階段。第一階段，加入該組的服務器選擇該組上的一個在線服務器作爲其缺失狀態的捐贈者。捐贈者負責爲新服務器提供加入該組的所有數據，直到它加入該組爲止。這是通過在捐贈者和加入該組的服務器之間建立的標準異步複製通道來實現的。複製通道是MySQL 5.7 中提出的概念。簡單講一個複製通道表示從主庫到從庫的一條複製路徑，在多源複製中主到從可以存在多條複製通道。通過此複製通道複製捐贈者的二進制日誌，直到加入該組的服務器成爲該組的一部分，併發生視圖更改時。加入該組的服務器在收到捐贈者的二進制日誌時應用它們。
複製二進制日誌時，加入該組的服務器還會緩存在組內交換的每個事務。也就是說，它監聽在加入該組之後發生的事務，同時應用來自捐贈者的數據。當第一階段結束並且關閉捐贈者的複製通道時，加入該組的服務器開始第二階段：追趕。在此階段，加入組的服務器繼續執行高速緩存的事務。排隊等待執行的事務數最終達到零時，該成員將在線聲明。
當加入組的服務器從捐贈者獲取二進制日誌時，恢復過程可以承受捐贈者故障。在這種情況下，捐贈者在第一階段期間失敗時，加入該組的服務器將故障轉移到新的捐贈者並從新捐贈者恢復。加入該組的服務器將關閉與失敗的捐贈者的連接，並打開與新捐贈者的連接，這些都是自動進行的。
（2）基於時間點的恢復
爲了使加入組的服務器與捐贈者同步到特定時間點，加入組和捐贈者的服務器利用MySQL全局事務標識符（GTID）機制。但GTID僅提供了一種方法來發現加入該組的服務器缺少哪些事務，不會傳達認證信息。這是二進制日誌視圖標記的工作，它標記二進制日誌流中的視圖更改，還包含其它元數據信息，如認證相關數據。
視圖對應於主動參與當前配置的一組成員，在特定時間點，這些組成員在系統中是正確的和在線的。視圖更改發生在組配置修改（例如成員加入或離開）時。任何組成員身份更改都會導致在同一邏輯時間點向所有成員傳達視圖更改。視圖標識符唯一標識視圖。只要視圖發生更改，就會生成一個視圖標識符。
在通信層，視圖更改及其關聯的視圖ID是成員加入之前和之後數據變化的邊界。此概念通過新的二進制日誌事件實現：“視圖更改日誌事件”。因此視圖ID也成爲在組成員資格發生變化之前和之後傳輸的事務的標記。視圖標識符本身由兩部分構成：隨機部分和單調遞增整數部分。第一部分在創建組時生成，並且在組中至少有一個成員時保持不變。每次視圖更改發生時，第二部分都會遞增。隨機部分識別組的開始，增量部分標識組的改變。
（3）視圖更改
視圖更改時，執行以下步驟將標識符合併到二進制日誌事件：
1. 開始：穩定組
如圖5所示，所有服務器都在線並處理來自組的傳入事務。一些服務器複製的事務可能稍微落後，但最終它們會相同。此時該組充當一個分佈式數據庫副本。
2. 視圖更改：加入一個組成員
每當新成員加入組並因此執行視圖更改時，每個聯機服務器都會把視圖更改日誌事件排入隊列以備執行。在視圖更改之前，服務器上可能有一些屬於舊視圖的事務排隊進行應用，將視圖更改事件排在它們之後可確保正確標記何時發生了視圖更改。
同時，加入該組的服務器通過視圖的在線服務器列表中選擇捐贈者。如圖6所示，成員加入時生成視圖4，在線成員將此視圖更改事件寫入二進制日誌。
3. 狀態轉移：追趕
一旦加入該組的服務器選擇該組中的某服務器作爲捐贈者，則在兩者之間建立新的異步複製連接並且開始狀態轉移（第一階段）。這種與捐贈者的交互一直持續到服務器加入組的應用程序線程，該線程處理服務器進入組時所觸發的視圖更改日誌事件。加入該組的服務器從捐贈者複製，直到它到達與視圖改變相匹配的視圖標識符，如圖7所示。
加入該組的服務器知道它應該在哪個視圖標識符停止複製。由於視圖標識符在相同的邏輯時間被髮送到組中的所有成員，避免了複雜的GTID集合計算，因爲視圖ID清楚地標記了屬於每個組視圖的數據。
加入該組的服務器正在從捐贈者複製時，它也會緩存來自該組的傳入事務。最後它停止從捐贈者複製並切換到應用緩存的那些事務，如圖8所示。
4. 完成：趕上
當加入組的服務器識別出具有預期視圖標識符的視圖更改日誌事件時，終止與捐贈者的連接並開始應用緩存的事務。視圖更改日誌事件除了在二進制日誌中充當分隔標記，還扮演另一個角色。當新服務器進入組時，它傳達所有服務器感知的認證信息，即最後的視圖改變。如果沒有視圖更改事件，加入該組的服務器將沒有必要的信息對後續事務進行衝突檢測。
追趕的持續時間（第二階段）是不確定的，它取決於負載和進入組的事務的多少。此過程完全聯機，加入組的服務器在追趕時不會阻止組中的任何其它服務器。當進行到第二階段時，加入該組的服務器的事務可能落後，落後的多少取決於負載。
當加入組的服務器達到零排隊事務並且其存儲的數據等於其它成員時，其公共狀態將更改爲聯機，如圖9所示。
（4）分佈式恢復的使用建議和限制
分佈式恢復基於傳統的異步複製，如果加入組的服務器沒有數據或者只有非常舊的備份數據，恢復過程可能很慢。這意味着要在第一階段傳輸大量數據，新增服務器可能需要很長時間才能恢復。因此建議在將服務器添加到組之前，應該爲其配置已經在組中的服務器的相當近的快照。這最小化了第一階段的所需時間並減少了對捐贈服務器的影響，因爲它只需保傳輸較少的二進制日誌。