MySQL組復(fù)制背景信息詳情

本文主要給大家介紹MySQL組復(fù)制背景信息詳情，希望可以給大家補(bǔ)充和更新些知識(shí)，如有其它問(wèn)題需要了解的可以持續(xù)在億速云行業(yè)資訊里面關(guān)注我的更新文章的。 

創(chuàng)建容錯(cuò)系統(tǒng)的最常見(jiàn)方法是創(chuàng)建組件冗余，換句話說(shuō)，組件可以被移除，而系統(tǒng)應(yīng)該繼續(xù)按預(yù)期運(yùn)行。這就造成了一系列的挑戰(zhàn)，將這種系統(tǒng)的復(fù)雜性提高到一個(gè)完全不同的水平。具體而言，復(fù)制的數(shù)據(jù)庫(kù)需要同時(shí)維護(hù)和管理若干個(gè)server成員，而不只是一個(gè)。此外，當(dāng)多個(gè)server協(xié)同工作是，系統(tǒng)必須處理其他一些常見(jiàn)的分布式系統(tǒng)問(wèn)題，諸如斷網(wǎng)或腦裂等情況。

因此，最大的挑戰(zhàn)是將數(shù)據(jù)庫(kù)和數(shù)據(jù)復(fù)制的邏輯與若干個(gè)server以簡(jiǎn)單一致的方式協(xié)調(diào)運(yùn)行的邏輯相融合。換句話說(shuō)，也就是使多個(gè)server成員關(guān)于系統(tǒng)的狀態(tài)和系統(tǒng)每次變更的數(shù)據(jù)保持一致。這可以被概括為使多個(gè)server對(duì)于每個(gè)數(shù)據(jù)庫(kù)狀態(tài)轉(zhuǎn)換達(dá)成共識(shí)，從而使它們都作為一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)運(yùn)行，或者說(shuō)它們最終達(dá)到相同狀態(tài)。這就意味著它們需要作為（分布式）state machine運(yùn)行。

MySQL Group Replication提供了一種強(qiáng)大的server間協(xié)調(diào)機(jī)制的分布式state machine復(fù)制。組中的server成員會(huì)自動(dòng)地進(jìn)行協(xié)調(diào)。在單主模式下，組復(fù)制具有自動(dòng)選主功能，每次只有一個(gè)云服務(wù)器成員接受更新。在多主模式下運(yùn)行時(shí)，所有的服務(wù)器成員都可以同時(shí)接受更新。這種功能就要求應(yīng)用程序不得不解決部署所帶來(lái)的限制。

有一個(gè)內(nèi)置的組成員服務(wù)，用于保持組視圖的一致性，并在任何給定的時(shí)間點(diǎn)對(duì)于所有server可用。當(dāng)Server離開(kāi)或加入組時(shí)，視圖會(huì)相應(yīng)地進(jìn)行更新。server也可能會(huì)意外離開(kāi)組，故障檢測(cè)機(jī)制會(huì)自動(dòng)檢測(cè)到此情況，并通知組該視圖已更改。

對(duì)于要提交的事務(wù)，決定提交或中止事務(wù)是由每個(gè)server單獨(dú)完成的，但所有組成員必須就該事務(wù)在全局事務(wù)序列中的順序達(dá)成一致意見(jiàn)。如果存在網(wǎng)絡(luò)分隔，造成組成員間無(wú)法達(dá)成協(xié)議，則系統(tǒng)在此問(wèn)題解決前將不會(huì)繼續(xù)運(yùn)行。因此，組復(fù)制還內(nèi)置了一個(gè)自動(dòng)的腦裂保護(hù)機(jī)制。

這種機(jī)制都是由系統(tǒng)提供的組通信協(xié)議（GCS）提供支持的。該協(xié)議保障了故障檢測(cè)機(jī)制，組成員服務(wù)的安全和消息的完全有序傳遞。該技術(shù)的核心是Paxos算法實(shí)現(xiàn)的，是組復(fù)制中保證數(shù)據(jù)一致性復(fù)制的關(guān)鍵， 它充當(dāng)了組通信系統(tǒng)的引擎。

18.1.1 復(fù)制技術(shù)

在介紹MySQL組復(fù)制的詳細(xì)信息之前，本節(jié)將簡(jiǎn)要介紹一些背景概念以及組復(fù)制是如何運(yùn)行的。通過(guò)本節(jié)我們可以了解組復(fù)制中需要什么，以及傳統(tǒng)異步MySQL復(fù)制和組復(fù)制之間的區(qū)別。

18.1.1.1 主-從復(fù)制

傳統(tǒng)的MySQL復(fù)制提供了一種簡(jiǎn)單的主–從復(fù)制方法。有一個(gè)主，以及一個(gè)或多個(gè)從。主節(jié)點(diǎn)執(zhí)行和提交事務(wù)，然后將它們（異步地）發(fā)送到從節(jié)點(diǎn)，以重新執(zhí)行（在基于語(yǔ)句的復(fù)制中）或應(yīng)用（在基于行的復(fù)制中）。這是一個(gè)shared-nothing的系統(tǒng)，默認(rèn)情況下所有server成員都有一個(gè)完整的數(shù)據(jù)副本。

圖18.1 MySQL異步復(fù)制

還有一個(gè)半同步復(fù)制，它在協(xié)議中添加了一個(gè)同步步驟。這意味著主節(jié)點(diǎn)在提交時(shí)需要等待從節(jié)點(diǎn)確認(rèn)它已經(jīng)接收到事務(wù)。只有這樣，主節(jié)點(diǎn)才能繼續(xù)提交操作。

圖18.2 MySQL半同步復(fù)制

在上面的兩個(gè)圖片中，可以看到傳統(tǒng)異步MySQL復(fù)制協(xié)議（以及半同步）的圖形展示。藍(lán)色箭頭表示在不同server之間或者server與client應(yīng)用之間的信息交互。

18.1.1.2 組復(fù)制

組復(fù)制是一種可用于實(shí)現(xiàn)容錯(cuò)系統(tǒng)的技術(shù)。復(fù)制組是一個(gè)通過(guò)消息傳遞相互交互的server集群。通信層提供了原子消息（atomic message）和完全有序信息交互等保障機(jī)制。這些是非常強(qiáng)大的功能，我們可以據(jù)此架構(gòu)設(shè)計(jì)更高級(jí)的數(shù)據(jù)庫(kù)復(fù)制解決方案。

MySQL組復(fù)制以這些功能和架構(gòu)為基礎(chǔ)，實(shí)現(xiàn)了基于復(fù)制協(xié)議的多主更新。復(fù)制組由多個(gè)server成員構(gòu)成，并且組中的每個(gè)server成員可以獨(dú)立地執(zhí)行事務(wù)。但所有讀寫(xiě)（RW）事務(wù)只有在沖突檢測(cè)成功后才會(huì)提交。只讀（RO）事務(wù)不需要在沖突檢測(cè)，可以立即提交。換句話說(shuō)，對(duì)于任何RW事務(wù)，提交操作并不是由始發(fā)server單向決定的，而是由組來(lái)決定是否提交。準(zhǔn)確地說(shuō)，在始發(fā)server上，當(dāng)事務(wù)準(zhǔn)備好提交時(shí)，該server會(huì)廣播寫(xiě)入值（已改變的行）和對(duì)應(yīng)的寫(xiě)入集（已更新的行的唯一標(biāo)識(shí)符）。然后會(huì)為該事務(wù)建立一個(gè)全局的順序。最終，這意味著所有server成員以相同的順序接收同一組事務(wù)。因此，所有server成員以相同的順序應(yīng)用相同的更改，以確保組內(nèi)一致。

在不同server上并發(fā)執(zhí)行的事務(wù)可能存在沖突。根據(jù)組復(fù)制的沖突檢測(cè)機(jī)制，對(duì)兩個(gè)不同的并發(fā)事務(wù)的寫(xiě)集合進(jìn)行檢測(cè)。如在不同的server成員執(zhí)行兩個(gè)更新同一行的并發(fā)事務(wù)，則會(huì)出現(xiàn)沖突。排在最前面的事務(wù)可以在所有server成員上提交，第二個(gè)事務(wù)在源server上回滾，并在組中的其他server上刪除。這就是分布式的先提交當(dāng)選規(guī)則。

圖18.3 MySQL組復(fù)制協(xié)議

最后，組復(fù)制是一種share-nothing復(fù)制方案，其中每個(gè)server成員都有自己的完整數(shù)據(jù)副本。

上圖描述了MySQL組復(fù)制協(xié)議，并通過(guò)將其與MySQL復(fù)制（MySQL半同步復(fù)制）進(jìn)行比較，可以看到一些差異。需要注意的是，這個(gè)圖片中不包含一些基本共識(shí)和Paxos相關(guān)的信息。

18.1.2 組復(fù)制用例

組復(fù)制使您能夠根據(jù)在一組server中復(fù)制系統(tǒng)的狀態(tài)來(lái)創(chuàng)建具有冗余的容錯(cuò)系統(tǒng)。因此，只要它不是全部或多數(shù)server發(fā)生故障，即使有一些server故障，系統(tǒng)仍然可用，最多只是性能和可伸縮性降低，但它仍然可用。server故障是孤立并且獨(dú)立的。它們由組成員服務(wù)來(lái)監(jiān)控，組成員服務(wù)依賴于分布式故障檢測(cè)系統(tǒng)，其能夠在任何server自愿地或由于意外停止而離開(kāi)組時(shí)發(fā)出信號(hào)。他們是由一個(gè)分布式恢復(fù)程序來(lái)確保當(dāng)有server加入組時(shí)，它們會(huì)自動(dòng)更新組信息到最新。并且多主更新確保了即使在單個(gè)服務(wù)器故障的情況下也不會(huì)阻止更新，不必進(jìn)行server故障轉(zhuǎn)移。因此，MySQL組復(fù)制保證數(shù)據(jù)庫(kù)服務(wù)持續(xù)可用。

值得注意的一點(diǎn)是，盡管數(shù)據(jù)庫(kù)服務(wù)可用，但當(dāng)有一個(gè)server崩潰時(shí)，連接到它的客戶端必須重定向或故障轉(zhuǎn)移到不同的server。這不是組復(fù)制要解決的問(wèn)題。連接器，負(fù)載均衡器，路由器或其他形式的中間件更適合處理這個(gè)問(wèn)題。

總之，MySQL組復(fù)制提供了高可用性，高彈性，可靠的MySQL服務(wù)。

18.1.2.1 用例場(chǎng)景示例

以下示例是組復(fù)制的典型用例。

• 彈性復(fù)制 - 需要非常流暢的復(fù)制基礎(chǔ)架構(gòu)環(huán)境，其中server的數(shù)量必須動(dòng)態(tài)增長(zhǎng)或收縮，并盡可能減少副作用。例如，云數(shù)據(jù)庫(kù)服務(wù)。

• 高可用分片 -分片是實(shí)現(xiàn)寫(xiě)擴(kuò)展的常用方法。使用MySQL組復(fù)制實(shí)現(xiàn)高可用性分片，其中每個(gè)分片映射到一個(gè)復(fù)制組。

• 替代主從復(fù)制- 在某些情況下，使用單個(gè)主服務(wù)器會(huì)造成單點(diǎn)爭(zhēng)用，寫(xiě)入整個(gè)組可能更具可擴(kuò)展性。

• 自動(dòng)系統(tǒng) -此外，您可以將MySQL組復(fù)制直接部署到已有復(fù)制協(xié)議的自動(dòng)化系統(tǒng)中（在本章和前面的章節(jié)中已經(jīng)描述過(guò)）。

18.1.3 組復(fù)制詳細(xì)信息

本節(jié)介紹有關(guān)組復(fù)制基礎(chǔ)服務(wù)的詳細(xì)信息。

18.1.3.1 故障檢測(cè)

組復(fù)制提供了一種故障檢測(cè)機(jī)制，它能夠找到并報(bào)告哪些server成員是無(wú)響應(yīng)的，并且假定這些server已死。在更高級(jí)別來(lái)說(shuō)，故障檢測(cè)是提供關(guān)于哪些server可能已死的信息（猜測(cè)）的分布式服務(wù)。然后，如果組同意該猜測(cè)可能是真的，則組判定給定的server確實(shí)已經(jīng)failed。這意味著組中的其余成員進(jìn)行協(xié)調(diào)決定以排除給定成員。

某個(gè)server無(wú)響應(yīng)時(shí)觸發(fā)猜測(cè)， 當(dāng)server A在給定時(shí)間段內(nèi)沒(méi)有從server B接收消息時(shí)，將會(huì)發(fā)生超時(shí)并且觸發(fā)猜測(cè)。

如果某個(gè)server與組的其余成員隔離，則它會(huì)懷疑所有其他server都失敗了。由于無(wú)法與組達(dá)成協(xié)議（因?yàn)樗鼰o(wú)法確保仲裁成員數(shù)），其懷疑不會(huì)產(chǎn)生后果。當(dāng)服務(wù)器以此方式與組隔離時(shí)，它無(wú)法執(zhí)行任何本地事務(wù)。

18.1.3.2 組成員關(guān)系

MySQL組復(fù)制依賴于組成員服務(wù)。這是一個(gè)內(nèi)置的插件。它定義了哪些server在線并在組中。在線server列表通常稱為視圖。因此，組中的每個(gè)server對(duì)于給定時(shí)刻積極參與組中的成員具有一致的視圖。

同組server不僅需要關(guān)于事務(wù)提交必須達(dá)成一致意見(jiàn)，關(guān)于當(dāng)前視圖也是。因此，如果同組server同意新的server加入，則該組本身將被重新配置從而將該server加入其中，并觸發(fā)視圖更新。相反，如果server離開(kāi)組，無(wú)論自愿或被迫的情況，該組都會(huì)動(dòng)態(tài)地重新規(guī)劃其配置，并觸發(fā)視圖更新。

要注意的是，當(dāng)成員自愿離開(kāi)時(shí)，它首先啟動(dòng)組的動(dòng)態(tài)重新配置。這觸發(fā)一個(gè)過(guò)程，其中所有成員必須就不包含已離開(kāi)server的新視圖達(dá)成一致。然而，如果成員由于發(fā)生意外而離開(kāi)（例如它意外停止或網(wǎng)絡(luò)連接斷開(kāi)），則故障檢測(cè)機(jī)制檢測(cè)到后，將提出該組的重新配置，去除故障成員。如上所述，這需要來(lái)自組中大多數(shù)服務(wù)器達(dá)成一致意見(jiàn)。如果組不能夠達(dá)成一致（例如，當(dāng)大多數(shù)服務(wù)器都不在線的情況），則系統(tǒng)不能動(dòng)態(tài)地改變配置，而且系統(tǒng)會(huì)鎖定以防止腦裂情況的發(fā)生。最終，這意味著管理員需要介入并解決這個(gè)問(wèn)題。

18.1.3.3 容錯(cuò)

MySQL組復(fù)制構(gòu)建在Paxos分布式算法實(shí)現(xiàn)的基礎(chǔ)上，以提供不同server之間的分布式協(xié)調(diào)。因此，它需要大多數(shù)server處于活動(dòng)狀態(tài)以達(dá)到仲裁成員數(shù)，從而做出決定。這對(duì)系統(tǒng)可以容忍的不影響其自身及其整體功能的故障數(shù)量有直接影響。容忍f個(gè)故障所需的server數(shù)量（n）為n = 2×f + 1。

在實(shí)踐中，這意味著為了容忍一個(gè)故障，組必須有三個(gè)server。因此，如果一個(gè)服務(wù)器故障，仍然有兩個(gè)服務(wù)器形成大多數(shù)（三分之二）來(lái)允許系統(tǒng)自動(dòng)地繼續(xù)運(yùn)行。但是，如果第二個(gè)server意外地fail掉，則該組（剩下一個(gè)server）鎖定，因?yàn)闆](méi)有多數(shù)可以達(dá)成決議。

以下是說(shuō)明上述公式的小表。

看了以上關(guān)于MySQL組復(fù)制背景信息詳情，希望能給大家在實(shí)際運(yùn)用中帶來(lái)一定的幫助。本文由于篇幅有限，難免會(huì)有不足和需要補(bǔ)充的地方，如有需要更加專業(yè)的解答，可在官網(wǎng)聯(lián)系我們的24小時(shí)售前售后，隨時(shí)幫您解答問(wèn)題的。