MySQL InnoDB Cluster 詳解

導(dǎo)讀
本文轉(zhuǎn)載自MySQL解決方案工程師
作者：徐鐵韜
這篇文章將詳細(xì)地介紹MySQL的高可用解決方案—— MySQL InnoDB Cluster暖混。

說到高可用性轮洋，首先要了解一下什么是高可用性硼被？

image

高可用性要求的實(shí)際上是對可靠性的要求食棕，從本質(zhì)上來說呐萌，是通過技術(shù)和工具來提高可靠性馁痴，盡可能長時間保持?jǐn)?shù)據(jù)的可用和系統(tǒng)的正常運(yùn)行時間。實(shí)現(xiàn)高可用性的原則為排除單點(diǎn)故障肺孤、通過冗余實(shí)現(xiàn)快速恢復(fù)罗晕，并且具有容錯機(jī)制。

image

上面一頁主要介紹了幾個關(guān)鍵詞匯赠堵，以及相關(guān)的定義小渊，這些有助于理解可靠性和高可用性。

image

MySQL的高可用性解決方案目前大致分為5種茫叭，按照高可用的級別（99.9999%為最高級）排序依次為酬屉，主從復(fù)制、具有自動故障轉(zhuǎn)移功能的主從復(fù)制揍愁、利用共享存儲梆惯、OS或虛擬化軟件實(shí)現(xiàn)主備架構(gòu)、MySQL Group Replication 群組復(fù)制吗垮，以及MySQL NDB Cluster垛吗。

MySQL Replication：允許數(shù)據(jù)從一臺實(shí)例上復(fù)制到一臺或多臺其它的實(shí)例上。
MySQL Group Replication：群組復(fù)制提供更好的冗余性烁登、自動恢復(fù)以及寫入擴(kuò)展怯屉。
MySQL InnoDB Cluster：基于群組復(fù)制，提供了易于管理的API饵沧、應(yīng)用故障轉(zhuǎn)移和路由锨络、易于配置，提供比群組復(fù)制更高級別的可用性狼牺。
MySQL NDB Cluster：容易與MySQL InnoDB Cluster混淆羡儿，是另外一款產(chǎn)品，提供更高級別的可用性和冗余性是钥。適用于分布式計算環(huán)境掠归，使用內(nèi)存型的NDB存儲引擎。關(guān)于這款產(chǎn)品的詳細(xì)內(nèi)容將不會在這里介紹悄泥。

image

在這里簡明介紹一下以復(fù)制為基礎(chǔ)的三種方案的基本原理虏冻。

經(jīng)典的主從復(fù)制是MySQL原生的復(fù)制功能，采用異步方式弹囚，如圖片最上面顯示的原理厨相，主服務(wù)器執(zhí)行更改數(shù)據(jù)的事務(wù)后，會產(chǎn)生binlog，之后binlog會被發(fā)送到從服務(wù)器變成relay log蛮穿，與此同時庶骄，主服務(wù)器會對應(yīng)用提交返回。從服務(wù)器接收到relay log后践磅，會通過一個applier的線程對日志里面的內(nèi)容進(jìn)行施放瓢姻，使產(chǎn)生的數(shù)據(jù)更改寫入從服務(wù)器，之后產(chǎn)生自己的binlog音诈，進(jìn)行提交幻碱。
采用異步的方式，在發(fā)生網(wǎng)絡(luò)問題和服務(wù)器損壞的情況下（從服務(wù)器未接收到日志细溅，主服務(wù)器已經(jīng)提交褥傍，并且提交后主服務(wù)器徹底損壞）會丟失數(shù)據(jù)，為了防止數(shù)據(jù)丟失喇聊，半同步復(fù)制在異步的基礎(chǔ)上增加了一個日志確認(rèn)的環(huán)節(jié)恍风，在從服務(wù)器接收到日志后，返回給主服務(wù)器一個應(yīng)答誓篱，之后主服務(wù)器才能對應(yīng)用提交返回朋贬。
作為MySQL目前最新的復(fù)制方式，群組復(fù)制MGR可以通過群組內(nèi)任意服務(wù)器對數(shù)據(jù)進(jìn)行更新窜骄，而不是像前面兩種有主從之分锦募。為此群組復(fù)制增加了一個驗(yàn)證步驟，通過驗(yàn)證的事務(wù)才能進(jìn)行提交邻遏，提交后群組內(nèi)其它成員同樣對日志進(jìn)行施放糠亩，提交。

image

MySQL InnoDB Cluster是一個高可用的框架准验，它由下面這幾個組件構(gòu)成：

MySQL Group Replication：提供DB的擴(kuò)展赎线、自動故障轉(zhuǎn)移
MySQL Router：輕量級中間件，提供應(yīng)用程序連接目標(biāo)的故障轉(zhuǎn)移
MySQL Shell：新的MySQL客戶端糊饱，多種接口模式垂寥。可以設(shè)置群組復(fù)制及Router
X DevAPI：一個API通過XProtocol與服務(wù)器通信
Admin API：一個特殊的API通過MySQL Shell使用另锋，可以用于對Innodb Cluster進(jìn)行配置管理

image

上圖顯示了InnoDB Cluster的整體架構(gòu)滞项，MySQL Router推薦部署在應(yīng)用端，通過MySQL Shell 對其進(jìn)行管理配置砰蠢，使用MySQL Enterprise Monitor對整體進(jìn)行監(jiān)控蓖扑。

image

InnoDB Cluster目前已經(jīng)實(shí)現(xiàn)了發(fā)展路線圖的第一步——高可用性唉铜，將來的發(fā)展方向?yàn)樽詣幼x取擴(kuò)展和自動寫入擴(kuò)展台舱。最終實(shí)現(xiàn)如下圖的最終目標(biāo)：

image

接下來的內(nèi)容，將詳細(xì)介紹一下MySQL Group Replication。

MGR實(shí)現(xiàn)了 Replicated Database State Machine理論竞惋，通信服務(wù)基于Paxos實(shí)現(xiàn)柜去，為MySQL5.7之后的版本提供同步復(fù)制（日志復(fù)制同步，數(shù)據(jù)施放異步）拆宛，并且支持所有的MySQL平臺嗓奢，包括Linux, Windows,Solaris, OSX, FreeBSD。

MGR提供了高可用分布式MySQL數(shù)據(jù)庫服務(wù)浑厚，它可以實(shí)現(xiàn)服務(wù)器自動故障轉(zhuǎn)移股耽，分布式容錯能力，支持多主更新的架構(gòu)钳幅，自動重配置（加入/移除節(jié)點(diǎn)物蝙，崩潰等等）并且可以自動偵測和處理沖突。

MGR適用的場景包括：

彈性復(fù)制-復(fù)制架構(gòu)下敢艰，服務(wù)器的數(shù)量動態(tài)增加或縮減時诬乞，使影響降到最低。
分片的高可用-用戶可以利用MGR實(shí)現(xiàn)單一分片的高可用钠导，每個分片都具有一個復(fù)制組震嫉。
主從復(fù)制的替代選擇-可以使用單主模式避免發(fā)生沖突檢測，以替代傳統(tǒng)的主從復(fù)制牡属。

image

上圖是MGR的架構(gòu)票堵，里面包括：

MySQL Group Replication插件

image

GR插件負(fù)責(zé)執(zhí)行分布式內(nèi)容，偵測和處理沖突逮栅，恢復(fù)分布式集群换衬，推送事務(wù)給其它的組成員，接收其它成員的事務(wù)以及決定事務(wù)最終的結(jié)果证芭。

GCS群組通信系統(tǒng)

GCS API將通信系統(tǒng)的實(shí)現(xiàn)進(jìn)行抽象化瞳浦，并管理這個接口。通信引擎是基于Paxos開發(fā)的废士，是實(shí)現(xiàn)跨服務(wù)器的組件叫潦。

image

MGR在使用時具有兩種模式，包括：

單主模式

image

該模式下官硝，單個MySQL實(shí)例作為數(shù)據(jù)寫入的主節(jié)點(diǎn)矗蕊，其它的節(jié)點(diǎn)用于熱備。這個模式與傳統(tǒng)的主從模式相似氢架，便于現(xiàn)有系統(tǒng)進(jìn)行切換傻咖。

image

多主模式

除了上面的單主模式，群組復(fù)制還具有多主模式岖研，與單主模式的主要區(qū)別在于卿操，群組內(nèi)所有的成員都可以進(jìn)行數(shù)據(jù)寫入警检、讀取操作。

使用多主模式時害淤，由于數(shù)據(jù)的寫入可以在所有的成員節(jié)點(diǎn)上進(jìn)行扇雕，當(dāng)在不同成員上對同一條記錄同時進(jìn)行更新時，就會產(chǎn)生沖突窥摄，此時群組復(fù)制會根據(jù)成員提交的先后次序（嚴(yán)格來講是在群組復(fù)制的一致性校驗(yàn)階段镶奉，取得校驗(yàn)成功的先后次序）進(jìn)行判斷，后提交事務(wù)的執(zhí)行回滾處理崭放。

image

沖突檢測需要使用主鍵哨苛。

image

由于多主模式需要確保數(shù)據(jù)寫入的一致性，所以在使用上有如下限制：

image

當(dāng)配置好MGR以后币砂，需要對其進(jìn)行監(jiān)視和管理移国，通過perforamnce_shcema里面的表和全局變量可以確認(rèn)MGR的成員狀態(tài)，當(dāng)前主成員等必要信息道伟。

image

群組復(fù)制的特性之一是提供高可用性迹缀，具有更好的容錯度。每個群組最多具有9個成員（推薦使用不超過7個蜜徽，最低使用3個祝懂。）

故障：（Ｆ）所需的服務(wù)器數(shù)量：（N）

N= 2F + 1

9成員的情況下，最多允許4個成員出現(xiàn)故障拘鞋。

image

使用MGR不會出現(xiàn)腦裂問題砚蓬，MGR會檢測網(wǎng)絡(luò)分區(qū)。

image

發(fā)生網(wǎng)絡(luò)分區(qū)時盆色，如果部分成員檢測到大多數(shù)成員丟失灰蛙，連接到這部分成員的數(shù)據(jù)更新處理將被擋住并等待，Select可以執(zhí)行隔躲。如下圖所示摩梧，S1 S2與其余三個成員失去聯(lián)系，對于S1 S2來說他們已經(jīng)丟失了群組中的大部分成員宣旱，因此不能夠在它們上面執(zhí)行數(shù)據(jù)更新處理（S3 S4 S5上面可以進(jìn)行數(shù)據(jù)更新仅父，當(dāng)網(wǎng)絡(luò)故障恢復(fù)后，S1 S2可以從S3 S4 S5上獲取故障期間未更新的數(shù)據(jù)）

image

MGR事實(shí)上也是一個分布式集群浑吟，讓我們看一下MGR是如何確保集群范圍內(nèi)的數(shù)據(jù)一致性笙纤。

MGR是通過日志的傳播和施放來進(jìn)行群組內(nèi)所有成員的數(shù)據(jù)同步，因此组力，在某一時間點(diǎn)各個成員上數(shù)據(jù)是會出現(xiàn)不一致的情況（最終會一致）省容。在MySQL8.0.14之后，可以通過使用變量 group_replication_consistency 精確地控制每個節(jié)點(diǎn)上數(shù)據(jù)的一致性燎字。

image

默認(rèn)的值為 EVENTUAL（最終一致）腥椒，如上圖所示阿宅，事務(wù)T1開始在M1上執(zhí)行，之后會將日志傳播到M2 M3寞酿，并對日志內(nèi)容進(jìn)行施放家夺。在日志內(nèi)容施放到M3之前脱柱，T2開始在M3上執(zhí)行伐弹，因此，T2沒有在最新的數(shù)據(jù)快照基礎(chǔ)上執(zhí)行榨为，如果T2與T1執(zhí)行的數(shù)據(jù)沒有關(guān)聯(lián)惨好，則可以采取該模式。

image

當(dāng)變量值設(shè)置為BEFORE時随闺，上圖中 T2使用該值日川，T2在M3上提交時，需要等待T1在全部成員上執(zhí)行完畢才可以執(zhí)行（T2要等待之前的事務(wù)BEFORE在全部成員上執(zhí)行完畢）

image

當(dāng)變量值設(shè)置為AFTER時矩乐，上圖中 T1使用該值龄句，T2在M3上提交時，需要等待T1在全部成員上執(zhí)行完畢才可以執(zhí)行（T1事務(wù)在全部成員上執(zhí)行完畢后,后面的事務(wù)（AFTER）才可以執(zhí)行）

image

如果事務(wù)執(zhí)行需要確保執(zhí)行前后都使用最新的數(shù)據(jù)快照散罕，則可以設(shè)置為BEFORE_AND_AFTER分歇。

MySQL Shell

image

接下來介紹一下MySQL Shell。Shell 是MySQL團(tuán)隊打造的一個統(tǒng)一的客戶端欧漱，它可以對MySQL執(zhí)行數(shù)據(jù)操作和管理职抡。它支持通過JavaScript，Python误甚，SQL對關(guān)系型數(shù)據(jù)模式和文檔型數(shù)據(jù)模式進(jìn)行操作缚甩。使用它可以輕松配置管理 InnoDB Cluster。

image

MySQL Shell里集成了一個特殊的管理API窑邦，可以通過它執(zhí)行DBA常見的操作擅威，后面會有一個詳細(xì)的使用例子介紹給大家。

MySQL Router

image

MySQL Router是一個輕量級的中間件冈钦，可以提供負(fù)載均衡和應(yīng)用連接的故障轉(zhuǎn)移裕寨。它是MySQL團(tuán)隊為MGR量身打造的，通過使用Router 和 Shell派继，用戶可以利用MGR實(shí)現(xiàn)完整的數(shù)據(jù)庫層的解決方案宾袜。如果您在使用MGR，請一定配合使用Router和Shell驾窟，您可以理解為它們是為MGR而生的庆猫，會配合MySQL的開發(fā)路線圖發(fā)展的工具。

InnoDB Cluster管理

讓我們看一下如何對InnoDB Cluster進(jìn)行管理绅络，我將會通過使用MySQL Shell為您展示相關(guān)內(nèi)容月培。