[mysql] 17.1.組復制 (MGR)

概要

Mysql組復制（MGR）是一個Mysql Server插件，使您可以創建彈性的，高可用性的，容錯的復制架構。

組可以在具有自動選舉的單主模式下運行，其中一次僅一個服務器接受請求。或者，對于更高級的用戶，可以以多主模式部署組，其中所有服務器都可以接受更新，即使它們是同時發布的。

有一個內置的組服務，它使組的視圖保持一致，并且在任何給定的時間點對所有服務器都可用。服務離線或者加入組，視圖會相應地更新。有時服務器可能會意外地脫離組，在這種情況下，故障檢測機制會全自動檢測到這一點并通知組視圖已更改。

組復制后臺進程

創建容錯系統的最常見方法是組件冗余，換句話說，移除組件，系統繼續按預期運行。這帶來了一系列挑戰，增加系統的復雜性。具體來說，復制數據庫必須處理好一個事實，它們需要維護和管理多個服務器，而不僅僅是一個服務器。此外，當服務器協同創建組時，還必須處理其他一些，如經典的分布式系統問題，如網絡分區或腦裂場景。

然而，最終的挑戰是將數據庫和數據復制以一致和簡單的方式，協調多個服務器的邏輯結合起來。換句話說，讓多個服務器就系統的狀態和系統每一次更改的數據達成一致。這可以概括為讓服務器在每個數據庫狀態轉換上達成一致，以便它們都作為一個數據庫進行處理，或者最終達到到相同的狀態。這意味著它們需要作為（分布式）狀態機運行。

MySQL組復制提供了分布式狀態的復制，服務器之間具有很強的協調性。當服務器屬于同一組時，它們會自動進行協調。組可以在具有自動選舉的單主模式下運行，其中一次僅一個服務器接受請求。或者，對于更高級的用戶，可以以多主模式部署組，其中所有服務器都可以接受更新，即使它們是同時發布的。當然這也是有一定限制的。

有一個內置的組服務，它使組的視圖保持一致，并且在任何給定的時間點對所有服務器都可用。服務離線或者加入組，視圖會相應地更新。有時服務器可能會意外地脫離組，在這種情況下，故障檢測機制會全自動檢測到這一點并通知組視圖已更改。

對于提交事務，組內多數成員必須在全局事務序列中的順序達成一致。每個服務器自身決定提交或中止事務，但所有服務器都做出相同的決定。如果存在網絡分區，導致成員無法達成協議的拆分，則在解決此問題之前，系統不會繼續進行。因此，也有一個內置的，自動的，分裂的保護機制。

這些都是組通信系統（GCS）協議提供支持。它們提供了故障檢測機制、組成員服務和安全有序的消息傳遞。所有這些屬性都是創建一個系統的關鍵，該系統可以確保數據在服務器組中一致地復制。這種技術的核心是Paxos算法的實現，它充當組通信引擎。

復制技術

Primary-Secondary Replication（主從復制）

MySQL復制提供了一種簡單的主從復制方法。有一個主（源）和一個或多個輔助（副本）。主服務器執行事務，提交，然后它們稍后（因此是異步的）被發送到輔助服務器，以便重新執行（在基于語句的復制中）或應用（在基于行的復制中）。它是不是一個共享系統，默認情況下，所有服務器都有一個完整的數據副本。

Figure?17.1?MySQL Asynchronous Replication

半同步復制，它為協議添加了一個同步步驟。這意味著主服務在提交時需要等待從服務器確認它已收到事務。只有這樣，主服務器才能繼續提交操作。

Figure?17.2?MySQL Semisynchronous Replication

在上面的兩張圖片中，您可以看到經典的異步MySQL復制協議（及其半同步）的示意圖。不同實例之間的箭頭表示服務器之間交換的消息或服務器與客戶機應用程序之間交換的消息。

Group Replication

組復制是一種可用于實現容錯的技術。復制組是一組服務，每個服務都有自己的完整數據副本（shared-nothing復制方案），并通過消息傳遞交互。通信層提供了一組保證，如原子消息和全序消息傳遞。這些非常強大的屬性可以轉化為非常有用的抽象，可以用來構建更高級的數據庫復制解決方案。

MySQL組復制建立在這些屬性和抽象之上，并實現了多源更新復制協議。復制組由多個服務組成，組中的每個服務可以隨時獨立地執行事務。但是，所有讀寫事務只有在得到組的批準后才提交。換句話說，對于任何讀寫事務，組需要決定是否提交，因此提交操作不是來自發起服務器的單方面決定。只讀事務不需要在組內進行協調，可以立即提交。

當讀寫事務準備在發起服務器上提交時，服務器會自動廣播寫入的值（已更改的行）和相應的寫入集（已更新行的唯一標識符）。因為事務是通過原子廣播發送的，所以組中的所有服務器要么接收事務，要么沒有服務器接收事務。如果他們接收到它，那么他們都會按照與之前發送的其他事務相同的順序接收它。因此，所有服務器都以相同的順序接收相同的事務集，并為這些事務建立全局總順序。

但是，在不同服務器上并發執行的事務之間可能存在沖突。在認證的過程中，通過檢查和比較兩個不同的并發事務的寫入集來檢測這種沖突。在認證期間，沖突檢測在行級別執行：如果在不同服務器上執行的兩個并發事務更新同一行，則存在沖突。沖突解決過程，第一個事務在所有服務器上有序提交，第二個事務有序中端，在發起服務器上回滾，并由組中的其他服務器進行丟棄操作。例如，如果t1和t2在不同的地方同時執行，它們都更改同一行，并且t2的順序在t1之前，那么t2繼續，t1被回滾。這實際上是一個分布式的首次提交wins規則。請注意，如果兩個事務綁定到沖突的頻率更高，那么最好在同一服務器上啟動它們，這樣它們就有機會在本地鎖管理器上同步，而不是由于認證結果而回滾。

對于應用和經過外部認證的事務，如果不破壞一致性和有效性，組復制允許服務器偏離約定的事務順序。組復制是一個最終的一致性系統，這意味著傳入的流量減慢或停止，所有組成員都具有相同的數據內容。當流量傳輸時，事務可能有稍微不同的順序，或者在某些成員上與在其他成員不一致。例如，在多主模式下，本地事務可能在認證之后立即externalized ，盡管在全局順序中較早的遠程事務尚未應用。當認證過程確定交易之間沒有沖突時，這是允許的。在單主模式下，在主服務器上，以與組復制商定的全局順序不同的順序提交和并發externalized 、無沖突的本地事務的可能性很小。在不接受客戶寫操作的第二方上，事務總是按照約定的順序提交和externalized 。

下圖描述了MySQL組復制協議，通過將其與MySQL復制（MySQL半同步復制）進行比較，可以看到一些差異。請注意，為了清晰起見，此圖中缺少一些基本共識和Paxos相關的消息

Figure?17.3?MySQL Group Replication Protocol

Group Replication Use Cases（使用案例）

組復制能夠通過將系統狀態復制到一組服務來創建具有冗余的容錯系統。即使某些服務隨后出現故障，只要不是全部或大部分，系統仍然可用。根據出現故障的服務數量，組可能會降低性能或可伸縮性，但仍然可用。服務故障是孤立和獨立的。它們由組成員服務跟蹤，該服務依賴于分布式故障檢測器，該檢測器能夠在任何服務器自動或由于意外停止而脫離組時發出信號。有一個分布式恢復過程來確保當服務器加入組時，它們會自動更新。不需要服務故障轉移，而且multi-source update everywhere 特性確保了即使是在單個服務器發生故障時，更新也不會被阻止?？傊?，MySQL組復制保證了數據庫服務的持續可用性。

重要的是要理解，盡管數據庫服務是可用的，但是在發生意外的服務器退出時，那些連接到它的客戶機必須重定向或故障轉移到不同的服務器。這不是組復制嘗試解決的問題。連接器、負載平衡器、路由器或某種形式的中間件更適合處理這個問題。例如，MySQL Router 8.0。

用例場景示例：

彈性復制—需要非常靈活的復制基礎結構的環境，在這種環境中，服務的數量必須動態增長或收縮，并且副作用盡可能少。例如，云數據庫服務。

高可用分片-分片是實現寫擴展的常用方法。使用MySQL組復制實現高可用的shard，其中每個shard映射到一個復制組。

替代Source-Replica 復制—在某些情況下，使用單個源服務器會使其成為單個爭用點。在某些情況下，向整個組寫入可能會更具伸縮性。

自主系統—此外，您可以部署MySQL組復制，這完全是為了復制協議中內置的自動化（在本章和前幾章中已經介紹過）。

Group Replication Details

Group Membership（組成員）

在MySQL組復制中，一組服務組成一個復制組。組有一個名稱，它采用UUID的形式。組是動態的，服務可以隨時離開（自愿或非自愿）并加入。每當服務加入或離開時，組都會自我調整。

如果服務器加入了組，它會通過從現有服務獲取丟失的狀態來自動更新自己。如果某個服務離開了組（例如，為了維護而關閉了該服務器），則其余的服務會注意到該服務器已離開，并自動重新配置該組。

組復制具有組成員服務，服務定義哪些服務器處于聯機狀態并參與組。聯機服務器列表稱為視圖。組中的每臺服務器都有一個一致的視圖，顯示哪些服務器是在給定時刻活躍的成員。

組成員不僅必須就事務提交達成一致，而且還必須就哪個是當前視圖達成一致。如果現有成員同意新服務器應成為組的一部分，則會重新配置組以將該服務器集成到其中，從而觸發視圖更改。如果服務器自愿或不自愿地離開組，則組會動態地重新排列其配置，并觸發視圖更改。

在成員自愿離開組的情況下，它首先啟動一個動態組重新配置，在此期間，所有成員必須在不離開服務的情況下就新視圖達成一致。但是，如果某個成員非自愿地離開組，例如因為它意外停止或網絡連接中斷，則它無法啟動重新配置。在這種情況下，組復制的故障檢測機制在短時間內識別出成員已經離開，并提出了一種沒有故障成員的組的重新配置方法。對于自愿離開的成員，重新配置需要得到組中大多數服務器的同意。但是，如果該組無法達成一致意見，例如因為其分區方式導致大多數服務器都無法聯機，則系統將無法動態更改配置，并阻止出現腦裂的情況。這種情況需要管理員的干預。

成員可以暫時脫機，然后在故障檢測機制檢測到其故障之前，以及在重新配置組以刪除成員之前，再次嘗試重新加入該組。在這種情況下，重新加入的成員會忘記其以前的狀態，但如果其他成員向其發送的消息是針對其崩潰前狀態的，這可能會導致包括可能的數據不一致在內的問題。如果這種情況下的成員參與了XCom's 的協商一致協議，則可能會導致XCom在失敗前后做出不同的決策，從而為同一輪協商一致協議提供不同的價值。

為了消除這種可能性，在MySQL 5.7.22中，服務器在加入組時會被賦予一個唯一的標識符。這使組復制能夠了解相同服務器的新化身（具有相同地址但具有新標識符）嘗試加入組而其舊化身仍列為成員的情況。新的化身被阻止加入組，直到舊的化身可以通過重新配置被移除。如果在服務器上停止并重新啟動組復制，則該成員將成為新的化身，并且在懷疑超時之前無法重新加入。

Failure Detection（故障探測）

組復制包括一種故障檢測機制，該機制能夠發現并報告哪些服務器處于靜默狀態，因此假定哪些服務器處于死機狀態。在較高的層次上，故障檢測器是一種分布式服務，它提供有關哪些服務可能已死亡（懷疑）的信息。服務器靜音時會引發懷疑。當服務器A在給定的時間段內沒有接收到來自服務器B的消息時，會發生超時并引發懷疑。稍后，如果該組同意懷疑可能是真的，則該組將確定給定的服務器確實發生了故障。這意味著組中的其余成員將協調一致地決定排除某個給定成員。

服務器靜音時會引發懷疑。當服務器A在給定的時間段內沒有接收到來自服務器B的消息時，會發生超時并引發懷疑。

如果一個服務器與組的其他部分隔離，那么它會懷疑其他所有服務器都失敗了。由于無法與組達成協議（因為它無法獲得選舉），其懷疑不會產生任何后果。當服務器以這種方式與組隔離時，它將無法執行任何本地事務。

Fault-tolerance（容錯）

MySQL組復制構建在Paxos分布式算法的實現之上，以提供服務器之間的分布式協調。因此，它需要大多數服務器處于活動狀態才能達到仲裁，從而做出決定。這直接影響到系統在不損害自身及其整體功能的情況下可以容忍的故障數量。因此，容忍f個故障所需的服務器數（n）為n=2 x 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

MySQL 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。