MySQL組復制背景信息詳情

本文主要給大家介紹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）鎖定，因為沒有多數可以達成決議。

以下是說明上述公式的小表。

看了以上關于MySQL組復制背景信息詳情，希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補充的地方，如有需要更加專業的解答，可在官網聯系我們的24小時售前售后，隨時幫您解答問題的。