这篇文章将详细地介绍 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个。)
故障:(F)所需的服务器数量:(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」圈子