【MySQL】組複製背景

原文：dev.mysql.com/doc/refman/… 譯者：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

下一章將涵蓋組複製技術方面的知識。