公眾號關注?「運維之美」設為「星標」，每天帶你玩轉 Linux ！

這篇文章將詳細地介紹 MySQL 的高可用解決方案—— MySQL InnoDB Cluster。

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

高可用性要求的實際上是對可靠性的要求，從本質上來說，是通過技術和工具來提高可靠性，盡可能長時間保持數據的可用和系統的正常運行時間。實現高可用性的原則為排除單點故障、通過冗余實現快速恢復，并且具有容錯機制。

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

MySQL的高可用性解決方案目前大致分為5種，按照高可用的級別(99.9999%為最高級)排序依次為，主從復制、具有自動故障轉移功能的主從復制、利用共享存儲、OS 或虛擬化軟件實現主備架構、MySQL Group Replication 群組復制，以及 MySQL NDB Cluster。MySQL Replication：允許數據從一臺實例上復制到一臺或多臺其它的實例上。

MySQL Group Replication：群組復制提供更好的冗余性、自動恢復以及寫入擴展。

MySQL InnoDB Cluster：基于群組復制，提供了易于管理的 API、應用故障轉移和路由、易于配置，提供比群組復制更高級別的可用性。

MySQL NDB Cluster：容易與 MySQL InnoDB Cluster 混淆，是另外一款產品，提供更高級別的可用性和冗余性。適用于分布式計算環境，使用內存型的 NDB 存儲引擎。關于這款產品的詳細內容將不會在這里介紹。

在這里簡明介紹一下以復制為基礎的三種方案的基本原理。經典的主從復制是 MySQL 原生的復制功能，采用異步方式，如圖片最上面顯示的原理，主服務器執行更改數據的事務后，會產生 binlog，之后 binlog 會被發送到從服務器變成 relay log，與此同時，主服務器會對應用提交返回。從服務器接收到 relay log 后，會通過一個 applier 的線程對日志里面的內容進行施放，使產生的數據更改寫入從服務器，之后產生自己的 binlog，進行提交。

采用異步的方式，在發生網絡問題和服務器損壞的情況下(從服務器未接收到日志，主服務器已經提交，并且提交后主服務器徹底損壞)會丟失數據，為了防止數據丟失，半同步復制在異步的基礎上增加了一個日志確認的環節，在從服務器接收到日志后，返回給主服務器一個應答，之后主服務器才能對應用提交返回。

作為 MySQL 目前最新的復制方式，群組復制 MGR 可以通過群組內任意服務器對數據進行更新，而不是像前面兩種有主從之分。為此群組復制增加了一個驗證步驟，通過驗證的事務才能進行提交，提交后群組內其它成員同樣對日志進行釋放，提交。

MySQL InnoDB Cluster是一個高可用的框架，它由下面這幾個組件構成：MySQL Group Replication：提供 DB 的擴展、自動故障轉移

MySQL Router：輕量級中間件，提供應用程序連接目標的故障轉移

MySQL Shell：新的 MySQL 客戶端，多種接口模式。可以設置群組復制及Router

X DevAPI：一個 API 通過 XProtocol 與服務器通信

Admin API：一個特殊的API通過 MySQL Shell 使用，可以用于對 Innodb Cluster 進行配置管理

上圖顯示了 InnoDB Cluster 的整體架構，MySQL Router 推薦部署在應用端，通過 MySQL Shell 對其進行管理配置，使用 MySQL Enterprise Monitor 對整體進行監控。

InnoDB Cluster 目前已經實現了發展路線圖的第一步——高可用性，將來的發展方向為自動讀取擴展和自動寫入擴展。最終實現如下圖的最終目標：

接下來的內容，將詳細介紹一下 MySQL Group Replication。

MGR 實現了 Replicated Database State Machine 理論，通信服務基于 Paxos 實現，為 MySQL 5.7 之后的版本提供同步復制(日志復制同步，數據施放異步)，并且支持所有的 MySQL 平臺，包括 Linux, Windows,Solaris, OSX, FreeBSD。

MGR 提供了高可用分布式 MySQL 數據庫服務，它可以實現服務器自動故障轉移，分布式容錯能力，支持多主更新的架構，自動重配置(加入/移除節點，崩潰等等)并且可以自動偵測和處理沖突。

MGR 適用的場景包括：彈性復制-復制架構下，服務器的數量動態增加或縮減時，使影響降到最低。

分片的高可用-用戶可以利用MGR實現單一分片的高可用，每個分片都具有一個復制組。

主從復制的替代選擇-可以使用單主模式避免發生沖突檢測，以替代傳統的主從復制。

上圖是 MGR 的架構，里面包括：

MySQL Group? Replication插件

GR插件負責執行分布式內容，偵測和處理沖突，恢復分布式集群，推送事務給其它的組成員，接收其它成員的事務以及決定事務最終的結果。

GCS群組通信系統

GCS API將通信系統的實現進行抽象化，并管理這個接口。通信引擎是基于Paxos開發的，是實現跨服務器的組件。

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

單主模式

該模式下，單個MySQL實例作為數據寫入的主節點，其它的節點用于熱備。這個模式與傳統的主從模式相似，便于現有系統進行切換。

多主模式

除了上面的單主模式，群組復制還具有多主模式，與單主模式的主要區別在于，群組內所有的成員都可以進行數據寫入、讀取操作。

使用多主模式時，由于數據的寫入可以在所有的成員節點上進行，當在不同成員上對同一條記錄同時進行更新時，就會產生沖突，此時群組復制會根據成員提交的先后次序(嚴格來講是在群組復制的一致性校驗階段，取得校驗成功的先后次序)進行判斷，后提交事務的執行回滾處理。

沖突檢測需要使用主鍵。

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

當配置好MGR以后，需要對其進行監視和管理，通過perforamnce_shcema里面的表和全局變量可以確認MGR的成員狀態，當前主成員等必要信息。

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

故障：(Ｆ)所需的服務器數量：(N)

N= 2F + 1

9 成員的情況下，最多允許 4 個成員出現故障。

使用 MGR 不會出現腦裂問題，MGR 會檢測網絡分區。

發生網絡分區時，如果部分成員檢測到大多數成員丟失，連接到這部分成員的數據更新處理將被擋住并等待，Select 可以執行。如下圖所示，S1 S2 與其余三個成員失去聯系，對于 S1 S2 來說他們已經丟失了群組中的大部分成員，因此不能夠在它們上面執行數據更新處理(S3 S4 S5上面可以進行數據更新，當網絡故障恢復后，S1 S2 可以從 S3 S4 S5 上獲取故障期間未更新的數據)

MGR 事實上也是一個分布式集群，讓我們看一下 MGR 是如何確保集群范圍內的數據一致性。

MGR 是通過日志的傳播和施放來進行群組內所有成員的數據同步，因此，在某一時間點各個成員上數據是會出現不一致的情況(最終會一致)。在MySQL 8.0.14 之后，可以通過使用變量 group_replication_consistency ?精確地控制每個節點上數據的一致性。

默認的值為 EVENTUAL(最終一致)，如上圖所示，事務 T1 開始在 M1 上執行，之后會將日志傳播到 M2 M3，并對日志內容進行施放。在日志內容施放到 M3 之前，T2 開始在 M3 上執行，因此，T2 沒有在最新的數據快照基礎上執行，如果 T2 與 T1 執行的數據沒有關聯，則可以采取該模式。

當變量值設置為?BEFORE時，上圖中?T2 使用該值，T2 在 M3 上提交時，需要等待 T1 在全部成員上執行完畢才可以執行(T2 要等待之前的事務?BEFORE在全部成員上執行完畢)

當變量值設置為AFTER時，上圖中?T1使用該值，T2在M3上提交時，需要等待T1在全部成員上執行完畢才可以執行(T1事務在全部成員上執行完畢后,后面的事務(AFTER)才可以執行)

如果事務執行需要確保執行前后都使用最新的數據快照，則可以設置為BEFORE_AND_AFTER。

MySQL Shell

接下來介紹一下 MySQL Shell。Shell 是MySQL團隊打造的一個統一的客戶端，它可以對 MySQL 執行數據操作和管理。它支持通過 JavaScript，Python，SQL 對關系型數據模式和文檔型數據模式進行操作。使用它可以輕松配置管理 InnoDB Cluster。

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

MySQL Router

MySQL Router 是一個輕量級的中間件，可以提供負載均衡和應用連接的故障轉移。它是 MySQL 團隊為 MGR 量身打造的，通過使用 Router 和 Shell，用戶可以利用 MGR 實現完整的數據庫層的解決方案。如果您在使用 MGR，請一定配合使用 Router 和 Shell，您可以理解為它們是為 MGR 而生的，會配合 MySQL 的開發路線圖發展的工具。

InnoDB Cluster 管理

讓我們看一下如何對 InnoDB Cluster 進行管理，我將會通過使用 MySQL Shell 為您展示相關內容。

使用 MySQL Shell 創建集群

首先執行了配置檢查，之后連接到mysql1:3306，然后執行dba.createCluster() 就可以創建一個集群，最后執行 cluster.addInstance() 就可以將其它成員加入到集群。使用起來是不是很簡單？

接下來是關于集群配置：

當新成員加入集群時，如果有缺失的事務，將會進行分布式恢復。

恢復時，可以采用增量恢復：

增量恢復可能會需要相當長的時間，并且當群組無法提供全部的 binlog 時，無法進行恢復。

幸好我們有克隆插件！

那么應該選擇使用哪種方式進行部署呢？

增量恢復:至少一個成員可以提供給新節點相同的已處理的事務集。

新節點不存在異于集群的事務

增量恢復適用于:事務未被清理

新節點不包含空的 GTID 集

啟用 GTID 和二進制日志

創建配置集群之后，介紹一下監控。

此外，Shell還提供了一個報表框架，并且支持用戶自定義報表

最后，介紹一下集群的維護和故障排除。

“任何可能出錯的地方都會出錯。”

默認情況下，Shell 為用戶提供了有價值的信息。但是有時需要更多信息來進行故障排除...

總結InnoDB Cluster 是 MySQL 內置的高可用解決方案

MySQL Clone 插件將 InnoDB 集群的可用性提升到了一個全新的高度！

InnoDB Cluster 功能內置了對完整實例配置的支持

MySQL Shell 是開發人員和 DBA 的統一接口以及 InnoDB Cluster 的前端管理器

本文比較長，能看完的都是真愛！感謝閱讀！

感謝關注 MySQL！本文轉載自：「MySQL解決方案工程師」，原文：https://url.cn/52gleog，版權歸原作者所有。歡迎投稿，投稿郵箱:editor@hi-linux.com

。

你可能還喜歡

點擊下方圖片即可閱讀

自從用上這張圖解指南后， Kubernetes 故障排除不再難！

點擊上方圖片，打開小程序，加入「玩轉 Linux」圈子

總結

以上是生活随笔為你收集整理的mysql高可靠部署_可能是我见过最好的 MySQL 高可用解决方案 MySQL InnoDB Cluster 中文教程！...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。