導讀
本文轉(zhuǎn)載自MySQL解決方案工程師
作者：徐鐵韜
這篇文章將詳細地介紹MySQL的高可用解決方案—— MySQL InnoDB Cluster。
說到高可用性，首先要了解一下什么是高可用性？
高可用性要求的實際上是對可靠性的要求，從本質(zhì)上來說，是通過技術(shù)和工具來提高可靠性，盡可能長時間保持數(shù)據(jù)的可用和系統(tǒng)的正常運行時間。實現(xiàn)高可用性的原則為排除單點故障、通過冗余實現(xiàn)快速恢復，并且具有容錯機制。
上面一頁主要介紹了幾個關鍵詞匯，以及相關的定義，這些有助于理解可靠性和高可用性。
MySQL的高可用性解決方案目前大致分為5種，按照高可用的級別（99.9999%為最高級）排序依次為，主從復制、具有自動故障轉(zhuǎn)移功能的主從復制、利用共享存儲、OS或虛擬化軟件實現(xiàn)主備架構(gòu)、MySQL Group Replication 群組復制，以及MySQL NDB Cluster。
MySQL Replication：允許數(shù)據(jù)從一臺實例上復制到一臺或多臺其它的實例上。
MySQL Group Replication：群組復制提供更好的冗余性、自動恢復以及寫入擴展。
MySQL InnoDB Cluster：基于群組復制，提供了易于管理的API、應用故障轉(zhuǎn)移和路由、易于配置，提供比群組復制更高級別的可用性。
MySQL NDB Cluster：容易與MySQL InnoDB Cluster混淆，是另外一款產(chǎn)品，提供更高級別的可用性和冗余性。適用于分布式計算環(huán)境，使用內(nèi)存型的NDB存儲引擎。關于這款產(chǎn)品的詳細內(nèi)容將不會在這里介紹。
在這里簡明介紹一下以復制為基礎的三種方案的基本原理。
經(jīng)典的主從復制是MySQL原生的復制功能，采用異步方式，如圖片最上面顯示的原理，主服務器執(zhí)行更改數(shù)據(jù)的事務后，會產(chǎn)生binlog，之后binlog會被發(fā)送到從服務器變成relay log，與此同時，主服務器會對應用提交返回。從服務器接收到relay log后，會通過一個applier的線程對日志里面的內(nèi)容進行施放，使產(chǎn)生的數(shù)據(jù)更改寫入從服務器，之后產(chǎn)生自己的binlog，進行提交。
采用異步的方式，在發(fā)生網(wǎng)絡問題和服務器損壞的情況下（從服務器未接收到日志，主服務器已經(jīng)提交，并且提交后主服務器徹底損壞）會丟失數(shù)據(jù)，為了防止數(shù)據(jù)丟失，半同步復制在異步的基礎上增加了一個日志確認的環(huán)節(jié)，在從服務器接收到日志后，返回給主服務器一個應答，之后主服務器才能對應用提交返回。
作為MySQL目前最新的復制方式，群組復制MGR可以通過群組內(nèi)任意服務器對數(shù)據(jù)進行更新，而不是像前面兩種有主從之分。為此群組復制增加了一個驗證步驟，通過驗證的事務才能進行提交，提交后群組內(nèi)其它成員同樣對日志進行施放，提交。
MySQL InnoDB Cluster是一個高可用的框架，它由下面這幾個組件構(gòu)成：
MySQL Group Replication：提供DB的擴展、自動故障轉(zhuǎn)移
MySQL Router：輕量級中間件，提供應用程序連接目標的故障轉(zhuǎn)移
MySQL Shell：新的MySQL客戶端，多種接口模式。可以設置群組復制及Router
X DevAPI：一個API通過XProtocol與服務器通信
Admin API：一個特殊的API通過MySQL Shell使用，可以用于對Innodb Cluster進行配置管理
上圖顯示了InnoDB Cluster的整體架構(gòu)，MySQL Router推薦部署在應用端，通過MySQL Shell 對其進行管理配置，使用MySQL Enterprise Monitor對整體進行監(jiān)控。
InnoDB Cluster目前已經(jīng)實現(xiàn)了發(fā)展路線圖的第一步——高可用性，將來的發(fā)展方向為自動讀取擴展和自動寫入擴展。最終實現(xiàn)如下圖的最終目標：
接下來的內(nèi)容，將詳細介紹一下MySQL Group Replication。
MGR實現(xiàn)了 Replicated Database State Machine理論，通信服務基于Paxos實現(xiàn)，為MySQL5.7之后的版本提供同步復制（日志復制同步，數(shù)據(jù)施放異步），并且支持所有的MySQL平臺，包括Linux, Windows,Solaris, OSX, FreeBSD。
MGR提供了高可用分布式MySQL數(shù)據(jù)庫服務，它可以實現(xiàn)服務器自動故障轉(zhuǎn)移，分布式容錯能力，支持多主更新的架構(gòu)，自動重配置（加入/移除節(jié)點，崩潰等等）并且可以自動偵測和處理沖突。
MGR適用的場景包括：
彈性復制-復制架構(gòu)下，服務器的數(shù)量動態(tài)增加或縮減時，使影響降到最低。
分片的高可用-用戶可以利用MGR實現(xiàn)單一分片的高可用，每個分片都具有一個復制組。
主從復制的替代選擇-可以使用單主模式避免發(fā)生沖突檢測，以替代傳統(tǒng)的主從復制。
上圖是MGR的架構(gòu)，里面包括：
MySQL Group Replication插件
GR插件負責執(zhí)行分布式內(nèi)容，偵測和處理沖突，恢復分布式集群，推送事務給其它的組成員，接收其它成員的事務以及決定事務最終的結(jié)果。
GCS群組通信系統(tǒng)
GCS API將通信系統(tǒng)的實現(xiàn)進行抽象化，并管理這個接口。通信引擎是基于Paxos開發(fā)的，是實現(xiàn)跨服務器的組件。
MGR在使用時具有兩種模式，包括：
單主模式
該模式下，單個MySQL實例作為數(shù)據(jù)寫入的主節(jié)點，其它的節(jié)點用于熱備。這個模式與傳統(tǒng)的主從模式相似，便于現(xiàn)有系統(tǒng)進行切換。
多主模式
除了上面的單主模式，群組復制還具有多主模式，與單主模式的主要區(qū)別在于，群組內(nèi)所有的成員都可以進行數(shù)據(jù)寫入、讀取操作。
使用多主模式時，由于數(shù)據(jù)的寫入可以在所有的成員節(jié)點上進行，當在不同成員上對同一條記錄同時進行更新時，就會產(chǎn)生沖突，此時群組復制會根據(jù)成員提交的先后次序（嚴格來講是在群組復制的一致性校驗階段，取得校驗成功的先后次序）進行判斷，后提交事務的執(zhí)行回滾處理。
沖突檢測需要使用主鍵。
由于多主模式需要確保數(shù)據(jù)寫入的一致性，所以在使用上有如下限制：
當配置好MGR以后，需要對其進行監(jiān)視和管理，通過perforamnce_shcema里面的表和全局變量可以確認MGR的成員狀態(tài)，當前主成員等必要信息。
群組復制的特性之一是提供高可用性，具有更好的容錯度。每個群組最多具有9個成員（推薦使用不超過7個，最低使用3個。）
故障：（Ｆ）所需的服務器數(shù)量：（N）
N= 2F + 1
9成員的情況下，最多允許4個成員出現(xiàn)故障。
使用MGR不會出現(xiàn)腦裂問題，MGR會檢測網(wǎng)絡分區(qū)。
發(fā)生網(wǎng)絡分區(qū)時，如果部分成員檢測到大多數(shù)成員丟失，連接到這部分成員的數(shù)據(jù)更新處理將被擋住并等待，Select可以執(zhí)行。如下圖所示，S1 S2與其余三個成員失去聯(lián)系，對于S1 S2來說他們已經(jīng)丟失了群組中的大部分成員，因此不能夠在它們上面執(zhí)行數(shù)據(jù)更新處理（S3 S4 S5上面可以進行數(shù)據(jù)更新，當網(wǎng)絡故障恢復后，S1 S2可以從S3 S4 S5上獲取故障期間未更新的數(shù)據(jù)）
MGR事實上也是一個分布式集群，讓我們看一下MGR是如何確保集群范圍內(nèi)的數(shù)據(jù)一致性。
MGR是通過日志的傳播和施放來進行群組內(nèi)所有成員的數(shù)據(jù)同步，因此，在某一時間點各個成員上數(shù)據(jù)是會出現(xiàn)不一致的情況（最終會一致）。在MySQL8.0.14之后，可以通過使用變量 group_replication_consistency 精確地控制每個節(jié)點上數(shù)據(jù)的一致性。
默認的值為 EVENTUAL（最終一致），如上圖所示，事務T1開始在M1上執(zhí)行，之后會將日志傳播到M2 M3，并對日志內(nèi)容進行施放。在日志內(nèi)容施放到M3之前，T2開始在M3上執(zhí)行，因此，T2沒有在最新的數(shù)據(jù)快照基礎上執(zhí)行，如果T2與T1執(zhí)行的數(shù)據(jù)沒有關聯(lián)，則可以采取該模式。
當變量值設置為BEFORE時，上圖中 T2使用該值，T2在M3上提交時，需要等待T1在全部成員上執(zhí)行完畢才可以執(zhí)行（T2要等待之前的事務BEFORE在全部成員上執(zhí)行完畢）
當變量值設置為AFTER時，上圖中 T1使用該值，T2在M3上提交時，需要等待T1在全部成員上執(zhí)行完畢才可以執(zhí)行（T1事務在全部成員上執(zhí)行完畢后,后面的事務（AFTER）才可以執(zhí)行）
如果事務執(zhí)行需要確保執(zhí)行前后都使用最新的數(shù)據(jù)快照，則可以設置為BEFORE_AND_AFTER。
MySQL Shell
接下來介紹一下MySQL Shell。Shell 是MySQL團隊打造的一個統(tǒng)一的客戶端，它可以對MySQL執(zhí)行數(shù)據(jù)操作和管理。它支持通過JavaScript，Python，SQL對關系型數(shù)據(jù)模式和文檔型數(shù)據(jù)模式進行操作。使用它可以輕松配置管理 InnoDB Cluster。
MySQL Shell里集成了一個特殊的管理API，可以通過它執(zhí)行DBA常見的操作，后面會有一個詳細的使用例子介紹給大家。
MySQL Router
MySQL Router是一個輕量級的中間件，可以提供負載均衡和應用連接的故障轉(zhuǎn)移。它是MySQL團隊為MGR量身打造的，通過使用Router 和 Shell，用戶可以利用MGR實現(xiàn)完整的數(shù)據(jù)庫層的解決方案。如果您在使用MGR，請一定配合使用Router和Shell，您可以理解為它們是為MGR而生的，會配合MySQL的開發(fā)路線圖發(fā)展的工具。
InnoDB Cluster管理
讓我們看一下如何對InnoDB Cluster進行管理，我將會通過使用MySQL Shell為您展示相關內(nèi)容。
使用MySQL Shell創(chuàng)建集群
首先執(zhí)行了配置檢查，之后連接到mysql1:3306，然后執(zhí)行dba.createCluster()就可以創(chuàng)建一個集群，最后執(zhí)行cluster.addInstance()就可以將其它成員加入到集群。使用起來是不是很簡單？
接下來是關于集群配置：
當新成員加入集群時，如果有缺失的事務，將會進行分布式恢復。
恢復時，可以采用增量恢復：
增量恢復可能會需要相當長的時間，并且當群組無法提供全部的binlog時，無法進行恢復。
幸好我們有克隆插件！
那么應該選擇使用哪種方式進行部署呢？
增量恢復:
至少一個成員可以提供給新節(jié)點相同的已處理的事務集。
新節(jié)點不存在異于集群的事務
增量恢復適用于:
事務未被清理
新節(jié)點不包含空的GTID集
啟用GTID 和二進制日志
創(chuàng)建配置集群之后，介紹一下監(jiān)控。
此外，Shell還提供了一個報表框架，并且支持用戶自定義報表
最后，介紹一下集群的維護和故障排除。
“任何可能出錯的地方都會出錯。”
默認情況下，Shell為用戶提供了有價值的信息。但是有時需要更多信息來進行故障排除...
總結(jié)：
InnoDB cluster 是MySQL內(nèi)置的高可用解決方案
MySQL Clone插件將InnoDB集群的可用性提升到了一個全新的高度！
InnoDB Cluster功能內(nèi)置了對完整實例配置的支持
MySQL Shell是開發(fā)人員和DBA的統(tǒng)一接口以及InnoDB Cluster的前端管理器
本文比較長，能看完的都是真愛！感謝閱讀！
感謝關注MySQL！
