可能是我见过最好的 MySQL 高可用解决方案 MySQL InnoDB Cluster 中文教程！
公众号关注 「运维之美」
设为「星标」，每天带你玩转 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，版权归原作者所有。欢迎投稿，投稿邮箱:
[email protected]。
你可能还喜欢
点击下方图片即可阅读
自从用上这张图解指南后， Kubernetes 故障排除不再难！
点击上方图片，打开小程序，加入「玩转 Linux」圈子
