MySQL 8 複製（七）——組複製基本原理

目錄

一、MySQL複製技術

1. 主從複製       

2. 組複製

二、組複製使用場景

三、組複製相關服務

1. 故障檢測

2. 組成員服務

3. 容錯

四、組複製技術細節

1. 組複製外掛體系結構

2. 複製組

3. 資料操作語言（Data Manipulation Language，DML）

4. 資料定義語句（Data Definition Language，DDL ）

5. 分散式恢復

        MySQL Group Replication（MGR）是MySQL 5.7.17版本引入的一個伺服器外掛，可用於建立高可用、可擴充套件、容錯的複製拓撲結構。組複製可以在單主模式下操作，其中只有一個伺服器接受更新，這個單主是系統自動選舉出來的。對於高階使用者，也可以部署為多主模式，其中所有伺服器都可以接受更新。內建的組成員服務可以在任何給定的時間點保持組的檢視一致並可供所有伺服器使用。當伺服器加入或離開組時，檢視也會相應更新。當伺服器當機，故障檢測機制會檢測到此情況並通知組其檢視已更改。這些都是自動進行的。

        建立容錯系統最常見的方法是元件冗餘。換句話說，一個元件被移除時，系統應該繼續按預期執行。這產生了一系列挑戰，將這種系統的複雜性提高到了一個完全不同的水平。資料複製必須維護和管理多個伺服器，還必須處理若干其它經典的分散式系統問題，如網路分割槽或腦裂。對MySQL而言，最終的挑戰是將資料複製邏輯與協調多個伺服器的邏輯相融合。這可以概括為讓每個伺服器的狀態在資料變化時達成一致，即便它們都作為單個資料庫系統執行，但最終都收斂到相同的狀態。

        MGR對屬於同一組的伺服器自動進行協調。對於要提交的事務，組成員必須就全域性事務序列中給定事務的順序達成一致。提交或回滾事務由每個伺服器單獨完成，但所有伺服器都必須做出相同的決定。如果存在網路分割槽，導致成員無法達成事先定義的分割策略，則在解決此問題之前系統不會繼續進行，這是一種內建的自動裂腦保護機制。MGR由組通訊系統（Group Communication System，GCS）協議支援。該系統提供故障檢測機制、組成員服務以及安全且有序的訊息傳遞。所有這些屬性都是建立系統的關鍵，可確保在伺服器組中一致地複製資料。該技術的核心是Paxos演算法的實現，它充當組通訊引擎。

一、MySQL複製技術

        在深入瞭解MySQL組複製的細節之前，先介紹一些其產生的背景以及工作原理，以幫助理解組複製，以及傳統非同步複製、半同步複製和組複製之間的區別。

1. 主從複製

       

        傳統的MySQL複製提供了一種簡單的主從複製方法。有一個主庫，一個或多個從庫。主庫執行並提交事務，然後透過二進位制日誌將事務相關的事件非同步傳送到從庫，以便重放。這是一個無共享系統，預設情況下所有伺服器都擁有完整的資料副本。

圖1 非同步複製

        半同步複製為非同步複製協議新增了一個同步步驟。這意味著主庫在提交時等待至少一個從庫確認它已收到該事務，才會繼續提交操作。

圖2 半同步複製

        圖1圖2分別表示MySQL非同步複製協議以及它的半同步變體。對角箭頭表示伺服器之間交換的訊息或伺服器與客戶端應用程式之間交換的訊息。

2. 組複製

        組由多個伺服器構成，透過傳遞訊息進行互動，通訊層保證原子訊息傳遞。MGR構建於此通訊層抽象之上，並實現了多主更新複製協議。組中的每個伺服器獨立地執行事務，但是所有讀寫事務只有在得到組的批准後才會提交。只讀事務在組內不需要協調，因此立即提交。對於任何讀寫事務，當事務準備好在始發伺服器處提交時，伺服器以原子方式廣播寫入值（更改的行）和對應的寫入集（更新的行的唯一識別符號），然後將該事務加入全域性事務列表。最終所有伺服器都以相同的順序接收並應用相同的事務集，所以它們在組內保持一致。

        不同伺服器上併發執行的事務之間可能存在衝突。MGR在certify過程中檢查併發事務的寫集來檢測這種衝突。如果在不同伺服器上執行的兩個併發事務更新同一行，則存在衝突。解決方案是先到事務提交，後到事務回滾，即按順序第一個事務在所有伺服器提交，而第二個事務在在原始伺服器上回滾並在組中的其它伺服器中刪除。這實際上體現的是多主分散式事務的首個提交獲勝原則。

圖3 MGR協議

        圖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外掛架構。

圖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所示，所有伺服器都線上並處理來自組的傳入事務。一些伺服器複製的事務可能稍微落後，但最終它們會相同。此時該組充當一個分散式資料庫副本。

圖5 穩定組

 

        2. 檢視更改：加入一個組成員

        每當新成員加入組並因此執行檢視更改時，每個聯機伺服器都會把檢視更改日誌事件排入佇列以備執行。在檢視更改之前，伺服器上可能有一些屬於舊檢視的事務排隊進行應用，將檢視更改事件排在它們之後可確保正確標記何時發生了檢視更改。

        同時，加入該組的伺服器透過檢視的線上伺服器列表中選擇捐贈者。如圖6所示，成員加入時生成檢視4，線上成員將此檢視更改事件寫入二進位制日誌。

圖6 成員加入

 

        3. 狀態轉移：追趕

        一旦加入該組的伺服器選擇該組中的某伺服器作為捐贈者，則在兩者之間建立新的非同步複製連線並且開始狀態轉移（第一階段）。這種與捐贈者的互動一直持續到伺服器加入組的應用程式執行緒，該執行緒處理伺服器進入組時所觸發的檢視更改日誌事件。加入該組的伺服器從捐贈者複製，直到它到達與檢視改變相匹配的檢視識別符號，如圖7所示。

圖7 追趕

 

        加入該組的伺服器知道它應該在哪個檢視識別符號停止複製。由於檢視識別符號在相同的邏輯時間被髮送到組中的所有成員，避免了複雜的GTID集合計算，因為檢視ID清楚地標記了屬於每個組檢視的資料。

        加入該組的伺服器正在從捐贈者複製時，它也會快取來自該組的傳入事務。最後它停止從捐贈者複製並切換到應用快取的那些事務，如圖8所示。

圖8 排隊的事務

 

        4. 完成：趕上

        當加入組的伺服器識別出具有預期檢視識別符號的檢視更改日誌事件時，終止與捐贈者的連線並開始應用快取的事務。檢視更改日誌事件除了在二進位制日誌中充當分隔標記，還扮演另一個角色。當新伺服器進入組時，它傳達所有伺服器感知的認證資訊，即最後的檢視改變。如果沒有檢視更改事件，加入該組的伺服器將沒有必要的資訊對後續事務進行衝突檢測。

        追趕的持續時間（第二階段）是不確定的，它取決於負載和進入組的事務的多少。此過程完全聯機，加入組的伺服器在追趕時不會阻止組中的任何其它伺服器。當進行到第二階段時，加入該組的伺服器的事務可能落後，落後的多少取決於負載。

        當加入組的伺服器達到零排隊事務並且其儲存的資料等於其它成員時，其公共狀態將更改為聯機，如圖9所示。

圖9 例項聯機

 

（4）分散式恢復的使用建議和限制

        分散式恢復基於傳統的非同步複製，如果加入組的伺服器沒有資料或者只有非常舊的備份資料，恢復過程可能很慢。這意味著要在第一階段傳輸大量資料，新增伺服器可能需要很長時間才能恢復。因此建議在將伺服器新增到組之前，應該為其配置已經在組中的伺服器的相當近的快照。這最小化了第一階段的所需時間並減少了對捐贈伺服器的影響，因為它只需保傳輸較少的二進位制日誌。

————————————————

版權宣告：本文為CSDN博主「wzy0623」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結及本宣告。

原文連結： https://blog.csdn.net/wzy0623/article/details/95195028

---

---

About Me

........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ xiaomaimiaolhr）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文CSDN地址： https://blog.csdn.net/lihuarongaini ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： ........................................................................................................................ ● QQ群號： 230161599 、618766405 ● 微 信群：可加我微 信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ），註明新增緣由 ● 於 2020-02-01 06:00 ~ 2020-02-31 24:00 在西安完成 ● 最新修改時間：2020-02-01 06:00 ~ 2020-02-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店： ● 小麥苗出版的資料庫類叢書： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 微 信客戶端掃描下面的二維碼來關注小麥苗的微 信公眾號（ xiaomaimiaolhr）及QQ群（DBA寶典）、新增小麥苗微 信， 學習最實用的資料庫技術。 ........................................................................................................................