本文主要給大家介紹MySQL組復(fù)制背景信息詳情，希望可以給大家補充和更新些知識，如有其它問題需要了解的可以持續(xù)在創(chuàng)新互聯(lián)行業(yè)資訊里面關(guān)注我的更新文章的。
成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供城東網(wǎng)站建設(shè)、城東做網(wǎng)站、城東網(wǎng)站設(shè)計、城東網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、城東企業(yè)網(wǎng)站模板建站服務(wù)，十多年城東做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
創(chuàng)建容錯系統(tǒng)的最常見方法是創(chuàng)建組件冗余，換句話說，組件可以被移除，而系統(tǒng)應(yīng)該繼續(xù)按預(yù)期運行。這就造成了一系列的挑戰(zhàn)，將這種系統(tǒng)的復(fù)雜性提高到一個完全不同的水平。具體而言，復(fù)制的數(shù)據(jù)庫需要同時維護和管理若干個server成員，而不只是一個。此外，當(dāng)多個server協(xié)同工作是，系統(tǒng)必須處理其他一些常見的分布式系統(tǒng)問題，諸如斷網(wǎng)或腦裂等情況。
因此，最大的挑戰(zhàn)是將數(shù)據(jù)庫和數(shù)據(jù)復(fù)制的邏輯與若干個server以簡單一致的方式協(xié)調(diào)運行的邏輯相融合。換句話說，也就是使多個server成員關(guān)于系統(tǒng)的狀態(tài)和系統(tǒng)每次變更的數(shù)據(jù)保持一致。這可以被概括為使多個server對于每個數(shù)據(jù)庫狀態(tài)轉(zhuǎn)換達(dá)成共識，從而使它們都作為一個獨立的數(shù)據(jù)庫運行，或者說它們最終達(dá)到相同狀態(tài)。這就意味著它們需要作為（分布式）state machine運行。
MySQL Group Replication提供了一種強大的server間協(xié)調(diào)機制的分布式state machine復(fù)制。組中的server成員會自動地進行協(xié)調(diào)。在單主模式下，組復(fù)制具有自動選主功能，每次只有一個云服務(wù)器成員接受更新。在多主模式下運行時，所有的服務(wù)器成員都可以同時接受更新。這種功能就要求應(yīng)用程序不得不解決部署所帶來的限制。
有一個內(nèi)置的組成員服務(wù)，用于保持組視圖的一致性，并在任何給定的時間點對于所有server可用。當(dāng)Server離開或加入組時，視圖會相應(yīng)地進行更新。server也可能會意外離開組，故障檢測機制會自動檢測到此情況，并通知組該視圖已更改。
對于要提交的事務(wù)，決定提交或中止事務(wù)是由每個server單獨完成的，但所有組成員必須就該事務(wù)在全局事務(wù)序列中的順序達(dá)成一致意見。如果存在網(wǎng)絡(luò)分隔，造成組成員間無法達(dá)成協(xié)議，則系統(tǒng)在此問題解決前將不會繼續(xù)運行。因此，組復(fù)制還內(nèi)置了一個自動的腦裂保護機制。
這種機制都是由系統(tǒng)提供的組通信協(xié)議（GCS）提供支持的。該協(xié)議保障了故障檢測機制，組成員服務(wù)的安全和消息的完全有序傳遞。該技術(shù)的核心是Paxos算法實現(xiàn)的，是組復(fù)制中保證數(shù)據(jù)一致性復(fù)制的關(guān)鍵， 它充當(dāng)了組通信系統(tǒng)的引擎。
在介紹MySQL組復(fù)制的詳細(xì)信息之前，本節(jié)將簡要介紹一些背景概念以及組復(fù)制是如何運行的。通過本節(jié)我們可以了解組復(fù)制中需要什么，以及傳統(tǒng)異步MySQL復(fù)制和組復(fù)制之間的區(qū)別。
傳統(tǒng)的MySQL復(fù)制提供了一種簡單的主–從復(fù)制方法。有一個主，以及一個或多個從。主節(jié)點執(zhí)行和提交事務(wù)，然后將它們（異步地）發(fā)送到從節(jié)點，以重新執(zhí)行（在基于語句的復(fù)制中）或應(yīng)用（在基于行的復(fù)制中）。這是一個shared-nothing的系統(tǒng)，默認(rèn)情況下所有server成員都有一個完整的數(shù)據(jù)副本。
圖18.1 MySQL異步復(fù)制
還有一個半同步復(fù)制，它在協(xié)議中添加了一個同步步驟。這意味著主節(jié)點在提交時需要等待從節(jié)點確認(rèn)它已經(jīng)接收到事務(wù)。只有這樣，主節(jié)點才能繼續(xù)提交操作。
圖18.2 MySQL半同步復(fù)制
在上面的兩個圖片中，可以看到傳統(tǒng)異步MySQL復(fù)制協(xié)議（以及半同步）的圖形展示。藍(lán)色箭頭表示在不同server之間或者server與client應(yīng)用之間的信息交互。
組復(fù)制是一種可用于實現(xiàn)容錯系統(tǒng)的技術(shù)。復(fù)制組是一個通過消息傳遞相互交互的server集群。通信層提供了原子消息（atomic message）和完全有序信息交互等保障機制。這些是非常強大的功能，我們可以據(jù)此架構(gòu)設(shè)計更高級的數(shù)據(jù)庫復(fù)制解決方案。
MySQL組復(fù)制以這些功能和架構(gòu)為基礎(chǔ)，實現(xiàn)了基于復(fù)制協(xié)議的多主更新。復(fù)制組由多個server成員構(gòu)成，并且組中的每個server成員可以獨立地執(zhí)行事務(wù)。但所有讀寫（RW）事務(wù)只有在沖突檢測成功后才會提交。只讀（RO）事務(wù)不需要在沖突檢測，可以立即提交。換句話說，對于任何RW事務(wù)，提交操作并不是由始發(fā)server單向決定的，而是由組來決定是否提交。準(zhǔn)確地說，在始發(fā)server上，當(dāng)事務(wù)準(zhǔn)備好提交時，該server會廣播寫入值（已改變的行）和對應(yīng)的寫入集（已更新的行的唯一標(biāo)識符）。然后會為該事務(wù)建立一個全局的順序。最終，這意味著所有server成員以相同的順序接收同一組事務(wù)。因此，所有server成員以相同的順序應(yīng)用相同的更改，以確保組內(nèi)一致。
在不同server上并發(fā)執(zhí)行的事務(wù)可能存在沖突。根據(jù)組復(fù)制的沖突檢測機制，對兩個不同的并發(fā)事務(wù)的寫集合進行檢測。如在不同的server成員執(zhí)行兩個更新同一行的并發(fā)事務(wù)，則會出現(xiàn)沖突。排在最前面的事務(wù)可以在所有server成員上提交，第二個事務(wù)在源server上回滾，并在組中的其他server上刪除。這就是分布式的先提交當(dāng)選規(guī)則。
圖18.3 MySQL組復(fù)制協(xié)議
最后，組復(fù)制是一種share-nothing復(fù)制方案，其中每個server成員都有自己的完整數(shù)據(jù)副本。
上圖描述了MySQL組復(fù)制協(xié)議，并通過將其與MySQL復(fù)制（MySQL半同步復(fù)制）進行比較，可以看到一些差異。需要注意的是，這個圖片中不包含一些基本共識和Paxos相關(guān)的信息。
組復(fù)制使您能夠根據(jù)在一組server中復(fù)制系統(tǒng)的狀態(tài)來創(chuàng)建具有冗余的容錯系統(tǒng)。因此，只要它不是全部或多數(shù)server發(fā)生故障，即使有一些server故障，系統(tǒng)仍然可用，最多只是性能和可伸縮性降低，但它仍然可用。server故障是孤立并且獨立的。它們由組成員服務(wù)來監(jiān)控，組成員服務(wù)依賴于分布式故障檢測系統(tǒng)，其能夠在任何server自愿地或由于意外停止而離開組時發(fā)出信號。他們是由一個分布式恢復(fù)程序來確保當(dāng)有server加入組時，它們會自動更新組信息到最新。并且多主更新確保了即使在單個服務(wù)器故障的情況下也不會阻止更新，不必進行server故障轉(zhuǎn)移。因此，MySQL組復(fù)制保證數(shù)據(jù)庫服務(wù)持續(xù)可用。
值得注意的一點是，盡管數(shù)據(jù)庫服務(wù)可用，但當(dāng)有一個server崩潰時，連接到它的客戶端必須重定向或故障轉(zhuǎn)移到不同的server。這不是組復(fù)制要解決的問題。連接器，負(fù)載均衡器，路由器或其他形式的中間件更適合處理這個問題。
總之，MySQL組復(fù)制提供了高可用性，高彈性，可靠的MySQL服務(wù)。
以下示例是組復(fù)制的典型用例。
彈性復(fù)制 - 需要非常流暢的復(fù)制基礎(chǔ)架構(gòu)環(huán)境，其中server的數(shù)量必須動態(tài)增長或收縮，并盡可能減少副作用。例如，云數(shù)據(jù)庫服務(wù)。
高可用分片 -分片是實現(xiàn)寫擴展的常用方法。使用MySQL組復(fù)制實現(xiàn)高可用性分片，其中每個分片映射到一個復(fù)制組。
替代主從復(fù)制- 在某些情況下，使用單個主服務(wù)器會造成單點爭用，寫入整個組可能更具可擴展性。
本節(jié)介紹有關(guān)組復(fù)制基礎(chǔ)服務(wù)的詳細(xì)信息。
組復(fù)制提供了一種故障檢測機制，它能夠找到并報告哪些server成員是無響應(yīng)的，并且假定這些server已死。在更高級別來說，故障檢測是提供關(guān)于哪些server可能已死的信息（猜測）的分布式服務(wù)。然后，如果組同意該猜測可能是真的，則組判定給定的server確實已經(jīng)failed。這意味著組中的其余成員進行協(xié)調(diào)決定以排除給定成員。
某個server無響應(yīng)時觸發(fā)猜測， 當(dāng)server A在給定時間段內(nèi)沒有從server B接收消息時，將會發(fā)生超時并且觸發(fā)猜測。
如果某個server與組的其余成員隔離，則它會懷疑所有其他server都失敗了。由于無法與組達(dá)成協(xié)議（因為它無法確保仲裁成員數(shù)），其懷疑不會產(chǎn)生后果。當(dāng)服務(wù)器以此方式與組隔離時，它無法執(zhí)行任何本地事務(wù)。
MySQL組復(fù)制依賴于組成員服務(wù)。這是一個內(nèi)置的插件。它定義了哪些server在線并在組中。在線server列表通常稱為視圖。因此，組中的每個server對于給定時刻積極參與組中的成員具有一致的視圖。
同組server不僅需要關(guān)于事務(wù)提交必須達(dá)成一致意見，關(guān)于當(dāng)前視圖也是。因此，如果同組server同意新的server加入，則該組本身將被重新配置從而將該server加入其中，并觸發(fā)視圖更新。相反，如果server離開組，無論自愿或被迫的情況，該組都會動態(tài)地重新規(guī)劃其配置，并觸發(fā)視圖更新。
要注意的是，當(dāng)成員自愿離開時，它首先啟動組的動態(tài)重新配置。這觸發(fā)一個過程，其中所有成員必須就不包含已離開server的新視圖達(dá)成一致。然而，如果成員由于發(fā)生意外而離開（例如它意外停止或網(wǎng)絡(luò)連接斷開），則故障檢測機制檢測到后，將提出該組的重新配置，去除故障成員。如上所述，這需要來自組中大多數(shù)服務(wù)器達(dá)成一致意見。如果組不能夠達(dá)成一致（例如，當(dāng)大多數(shù)服務(wù)器都不在線的情況），則系統(tǒng)不能動態(tài)地改變配置，而且系統(tǒng)會鎖定以防止腦裂情況的發(fā)生。最終，這意味著管理員需要介入并解決這個問題。
MySQL組復(fù)制構(gòu)建在Paxos分布式算法實現(xiàn)的基礎(chǔ)上，以提供不同server之間的分布式協(xié)調(diào)。因此，它需要大多數(shù)server處于活動狀態(tài)以達(dá)到仲裁成員數(shù)，從而做出決定。這對系統(tǒng)可以容忍的不影響其自身及其整體功能的故障數(shù)量有直接影響。容忍f個故障所需的server數(shù)量（n）為n = 2×f + 1。
在實踐中，這意味著為了容忍一個故障，組必須有三個server。因此，如果一個服務(wù)器故障，仍然有兩個服務(wù)器形成大多數(shù)（三分之二）來允許系統(tǒng)自動地繼續(xù)運行。但是，如果第二個server意外地fail掉，則該組（剩下一個server）鎖定，因為沒有多數(shù)可以達(dá)成決議。
以下是說明上述公式的小表。
| 組大小 | 多數(shù) | 允許的即時故障數(shù) |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
看了以上關(guān)于MySQL組復(fù)制背景信息詳情，希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補充的地方，如有需要更加專業(yè)的解答，可在官網(wǎng)聯(lián)系我們的24小時售前售后，隨時幫您解答問題的。
重慶分公司
重慶分公司
