1. MGR简介 | 深入浅出MGR

1. MGR简介 | 深入浅出MGR,第1张

MGR是MySQL Group Replication的缩写,即MySQL组复制。

在以往,我们一般是利用MySQL的主从复制或半同步复制来提供高可用解决方案,但这存在以下几个比较严重的问题:

因为上述几个明显的缺点,因此MySQL推出了全新的高可用解决方案 -- 组复制,这是本系列文章要着重介绍的新特性。

MGR是MySQL 5.7.17开始引入的,但随着5.7版本逐渐退出历史舞台(MySQL 5.7已于2020年10月起不再做大的功能更新,只有修修补补以及针对安全更新),更多MGR相关特性都只在MySQL 8.0上才有。

因此,如果线上还有基于MySQL 5.7版本的MGR环境的话,建议尽快升级、迁移到MySQL 8.0版本。进一步提醒,推荐MySQL 8.0.22及之后的版本,整体会更稳定可靠,也有些很不错的新功能(不只是MGR方面的)。

MGR具备以下几个特点:

MGR可以选择单主(Single-Primary)模式

如上图所示,一开始S1节点是Primary角色,提供读写服务。当它发生故障时,剩下的S2-S5节点会再投票选举出S2作为新的Primary角色提供读写服务,而S1节点再达到一定超时阈值后,就会被踢出。

亦可选择多主(Multi-Primary)模式(再次 强烈建议选用单主模式

如上图所示,一开始S1-S5所有节点都是Primary角色,都可以提供读写服务,任何一个节点发生故障时,只需要把指向这个节点的流量切换下就行。

上述两种架构模式下,应用端通过MySQL Router连接后端在MGR服务,当后端节点发生切换时,Router会自动感知,对应用端来说几乎是透明的,影响很小,架构上也更灵活。

首先来个MGR的技术架构图:

MGR是以Plugin方式嵌入MySQL,部署更灵活方便。

事务从Server层通过钩子(hook)进入MGR API接口层,再分发到各组件层,在组件层完成事务Capture/Apply/Recover,通过复制协议层(Replication Protocol Logics)传输事务,最后经由GCS协调事务在各节点的最终一致性。

MGR节点间由组通信系统(GCS)提供支持,它提供了故障检测机制、组成员角色管理,以及安全且有序的消息传递,这些机制可确保在各节点间一致地复制数据。这项技术的核心是Paxos算法的实现,在MySQL里称之为XCom,由它充当MGR的通信引擎。

对于要提交的事务,组中的多数派节点必须就全局事务序列中给定的事务顺序达成一致。各节点做出决定提交或中止事务的选择,但所有节点都要做出相同的决定。如果发生网络分区,导致节点间无法达成一致决定,则在网络恢复前,MGR无法工作。

MGR支持单主和多主两种模式,在单主模式下,各节点会自动选定主节点,只有该主节点能同时读写,而其他(从)节点只能只读。在多主模式下,所有节点都可以进行读写。

相对于MariaDB Galera Cluster(以及基于此技术的Percona XtraDB Cluster,下面为了书写方便,都统称为PXC),个人认为MGR具备以下几个优势:

相对于传统主从复制(Replication),我认为MGR的优势有以下几点:

以上是我根据MySQL、MariaDB、Percona的资料整理得到的观点,不一定准确和全面,有不完善的地方还请留言指正。

本节主要介绍了什么是MGR,MGR的技术架构概要,以及MGR相对PXC的几个技术优势。

MGR是MySQL四部战略走的关键一环,依靠MGR和MySQL Shell、MySQL Router已实现了读节点扩展,以及写节点扩展(MGR多主模式),下一步预计实现sharding,让我们拭目以待。

相信MGR也是MySQL未来几年的重头戏,建议跟紧方向,不要错过这班列车。

因个人水平有限,专栏中难免存在错漏之处,请勿直接复制文档中的命令、方法直接应用于线上生产环境。请读者们务必先充分理解并在测试环境验证通过后方可正式实施,避免造成生产环境的破坏或损害。

Enjoy GreatSQL :)

来也科技使用 MGR (MySQL Group Replication)作为私有部署时 MySQL 的高可用架构,一年多以来,服务众多用户,稳定性得到了极大的保障。

本文记录自内部分享,需要一定的 MySQL 基础。欢迎大家在评论区讨论、交流~

MySQL Group Replication(简称 MGR), MySQL 组复制。

MGR 是 MySQL 官方推出的一种基于 paxos 协议的状态机复制,实现了分布式下数据的最终一致性。MySQL 组复制提供了高可用、高扩展、高可靠的 MySQL 集群解决方案。

MGR 支持两种模式:单主、多主。其中单主模式是官方推荐的,也是在来也科技内部广泛应用的,我们接下来的内容都是以单主模式为背景的。

可能有同学会质疑,公有云上的高可用架构大多是主从啊,为什么来也科技要选择 MGR ?

那首先,我们就要知道 “主从” 和 MGR 的优缺点分别是什么?

来也科技作为一家重心放在 ToB 的企业,我们着重考虑私有部署时,如何保证客户环境的可用性。客户的环境,我们看不到,更无法控制,在这样的情况下,我们会尽量求稳。

维护主从高可用架构的应用,通常面向大规模集群运维,往往会引入复杂的交互和新的中间件。对于我们这种只需要部署一套集群的 ToB 需求,显然是不合适的。

综合考虑之下,我们选择 MGR 作为私有部署时的高可用架构。

    · 最少 3 个节点,最多 9 个节点

    · 节点越多,容错性越强,但交互越多,可能会影响效率

    · 存储引擎只能使用 InnoDB

    · 表中必须带有主键

    · 一次只能加入一个节点。如果一次性添加多个节点,可能能执行成功,也可能会报错

    · 只支持 IPv4 网络

    · 必须使用 row-base 格式的binlog

    · MGR 模式下不支持过滤指定信息的 *** 作

来也科技在给客户做私有部署时,如果客户提供 MySQL 高可用环境,那么会直接使用客户的环境。

否则,部署团队将为客户搭建三节点的 MGR 高可用架构。整体架构图:

如图所示,在应用和 MGR 集群的中间层选用多节点 proxysql 做路由,配置读写分离和故障检测机制,确保读写流量分发正确。proxysql 只要有一个节点存活,即可正常提供服务。(除非扛不住压力!)

在这种架构下,我们可以实现:

    · 如果主库发生故障 -- 自动切换    

    · 如果从库发生故障 -- 将其下线

对于底层的 MGR 集群,宕机一个 mysql 实例时,不影响业务正常使用;宕机两个 mysql 实例时,集群只可读,不可写(因为此时已经无法满足 paxos 的多数投票要求)

首先,我们以一个“一波三折”的场景为例,切实感受下 MGR 是如何运作的。

假设存在一个三节点的 MGR 集群,三个节点分别部署在三台实例上。

此时,应用发起一个事务执行请求。 单主模式下,只有primary node 可以接收请求:

   1. primary 接受到请求后,想组所有成员同步请求,进行事务认证。事务认证包含 3 个部分:

        1-1. 冲突检测

        1-2. gtid分配器

        1-3. 事务组提交信息分配器

    2. 如果检测失败

        2-1. primary:回滚

        2-2. secondary:丢弃  binlog event (冲突检测时带来的)

    3. 如果检测成功:

        3-1. primary :记 binlog, 分配 GTID

        3-2. secondary:将 binlog event (冲突检测时带来的)信息写入 relay log

    4. secondary 应用 relay log ,执行 sql ,并记录日志(通常情况下,我们建议将集群内所有 node 都配置在 seed 中,即:每个节点都可能成为 donor ,所以都要记 binlog)

以上,就是事务在 MGR 中完整的执行流程。

假设,运行一段时间后,其中某个 secondary 节点因服务器宕机原因脱离集群,且长时间未被发现。直至节前巡检时,才被报出来。

补充说明:来也监控项目已经提上日程了,部署后,便不会存在这个风险了。

此时,售后同学重启服务器,启动 mysql 实例(假设顺利启动),执行 start group_replication  *** 作。

这个命令会执行什么 *** 作呢?

本地恢复:应用自己本地 relay log 中的日志

全局恢复:从集群中活跃的节点中任选一个作为 donor,用 recovery 线程 dump 它的binlog,来恢复自己的数据

恢复线程 requestdump 建立与 donor 的复制关系,该函数携带了待恢复节点的 gtid_executed 信息。

donor 端逆序遍历 binlog 文件,通过判断 binlog 文件的 Previous-GTIDs 来找到第一个不属于 gtid_executed 的事务,从该事务开始进行数据复制。

命令执行过后,观察 replication_group_members 表的数据,如果目标节点的状态是 ONLINE,则视为集群恢复成功。

但我们假设此 *** 作并未成功,日志中有报错:the master has purged binary logs containing GTIDs that the slave requires

这个错误的意思是:节点脱离集群时间过长,已无法通过现存节点的 binlog 直接恢复了。

重做数据。当然是重做数据!

我们需要清除这个下线节点的信息,创建一个新的实例,选择任一正常节点进行数据全量备份,并将其应用至新实例上。

全量数据恢复完成后,执行 start group_replication 命令,开启 MGR 同步,追平数据后,MGR 会将节点状态置为 ONLINE,然后开始正常接收流量请求。

在传统的主从复制中,DBA 需要在 change master 时手动设置增量同步开始的 GTID(更早版本需要指定 binlog file 和 position)。

但是部署过 MGR 的同学会发现,MGR 同步时只需要指定用户名密码即可。那它是怎么找点的呢?

不同的备份方式,对应着不同的找点方式,接下来我们以 mysqldump 为例,详细的讲解下这个过程。

mysqldump 全量数据,使用 gtid_purged 记录备份时已经执行过的事务:

mysqldump --set-gtid-purged=ON --single-transaction --all-databases -uroot -p -h 127.0.0.1 >mgr.sql

查看生成的 sql 文件,可以看到开始处有相关标识:

在新节点上使用如下命令清空 GTID 信息:

STOP GROUP_REPLICATION

reset master

接下来,应用文件 source mgr.sql,红框圈起来的语句会被一起执行。

完成后,开启 MGR 同步,就会自动跳过这些标识为 purged 的事务了。

当有成员加入或退出时,组会自动调整自身结构:

    · 成员的加入和退出需走 paxos  协议,由多数成员同意后方可执行成功

    · 如果多数节点已经处于离线状态了,那么不可执行主动离组 *** 作(投票会无法通过)。

离组分为主动离组和被动离组:

    · 主动离组:

            只有执行 stop replication 命令才算主动离组

            相当于总数变为 n-1

            无论主动离组多少成员,都不会影响投票 

    · 被动离组:

            因故障等原因导致意外下线

            总数不变

            影响投票

            当有多数节点被动离组后,集群不可用

    1. group_replication_applier:该通道用于回放本地 relay log 中的日志。

    2. group_replication_recovery:当有节点加入 Group 时,需要用到另一个复制通道 group_replication_recovery,它是一个传统的 Master-Slave 异步复制通道。

MGR 常见的调优方式有三种,分别是:

    并行复制

    压缩

    调整 GCT

如果设置了并行复制 slave_parallel_workers,那么这些参数也要被设置,用于确保所有的组成员按照相同的顺序执行并提交事务:

    slave_preserve_commit_order=1

    slave_parallel_type=LOGICAL_CLOCK

压缩语句:

STOP GROUP_REPLICATION

SET GLOBALgroup_replication_compression_threshold = 2097152

START GROUP_REPLICATION

超出这个指定范围,就不压缩了。

官方文档中提示:当网络带宽成为瓶颈时,通过压缩消息,可以提高集群整体 30% - 40% 的性能。

mysql>SET GLOBAL group_replication_poll_spin_loops= 10000

GCT接收来自组和 MGR 插件的消息,处理与仲裁和故障检测相关的任务,发送一些保活的通讯消息,还处理 MySQLServer 与组之间传入和传出的事务。GCT 会等待队列中的传入消息。当队列中没有消息时,GCT将会进行等待。

在某些情况下,通过将这个等待配置得稍微长一些(进行主动等待),可以减少 *** 作系统执行上下文切换时从处理器中换出GCT线程的次数。

常见的安全手段有两种:

    1. 控制节点白名单。设置 group_replication_ip_whitelist 参数,不再此范围的节点,不允许加入

    2. 配置 SSL:

         new_member> SET GLOBAL group_replication_recovery_use_ssl=1

        new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem'

        new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem'

        new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem'

MySQL 5.7.22 之前,可能会出现数据不一致的风险。这种情况发生在成员短暂离组,在组感知前,自己又重新加入组内的时候,官方文档描述如下:

In this situation, the rejoining member forgets its previousstate, but if other members send it messages that are intended for itspre-crash state, this can cause issues including possible data inconsistency.

To counter this possibility, from MySQL 5.7.22, servers aregiven a unique identifier when they join a group . This enables GroupReplication to be aware of the situation where a new incarnation of the sameserver (with the same address but a new identifier) is trying to join the groupwhile its old incarnation is still listed as a member. The new incarnation isblocked from joining the group until the old incarnation can be removed by areconfiguration. If Group Replication is stopped and restarted on the server,the member becomes a new incarnation and cannot rejoin until the suspiciontimes out.

精准的定位问题是解决问题和优化系统的前提!当集群故障时,我们首先要判断集群当前处于什么状态,优先恢复使用,尽可能地保留现场进行故障排查和恢复。

所有节点上执行查看集群成员信息命令:

Q: 为什么要在所有节点上执行?

A: 因为可能会发生网络分区,出现若干节点互联,分成若干集群的情况。集群一旦分裂,互相感知不到对方存在。

以三个节点为例,常见分裂拓扑图:

如果大多数节点存活(n=2f + 1 ) 且在同一个 group 中提供服务,我们认为,这仍是一个可用集群。

即:同一个 group 中 node 数大于 f ,且状态都是 ONLINE 的情况下,认定集群可用。

此时,优先使用可用集群提供服务,并进行后续问题排查。

主节点提供读写服务,从节点提供只读服务。

无论是应用直连,还是通过代理层(proxy 等)进行连接,当务之急都是确认主节点是谁。

命令:select MEMBER_HOST, MEMBER_PORT,MEMBER_STATE from performance_schema.replication_group_members m inner join performance_schema.global_status g on m.MEMBER_ID=g.VARIABLE_VALUE and VARIABLE_NAME = 'group_replication_primary_member'

知晓谁是主节点,谁是从节点后,应用或者代理,就可以进行相应的配置。

错误日志!错误日志!错误日志!

有故障,第一时间查看错误日志。错误日志存放位置:

打开日志文件,查看错误信息。

注意: 错误信息,不仅要在出故障的实例上查看。因为 MGR 是”大多数原则“,所以每一个实例上的错误信息,都可能不是完全的。

比如实例意外 down 掉,此时故障实例本身就可能来不及记录错误日志。

除了实例级别的错误日志外,MGR 视图还可能自己记录最后的错误信息,通常日志中会有相关提示。比如,日志中存在:

[ERROR] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'

常见错误:[GCS]Connection attempt from IP address 192.168.9.208 refused

出现场景:MGR 白名单设置不正确

解决办法:查看该实例所在的网段,是否在 MGR 的白名单中

命令:show global variables like 'group_replication_ip_whitelist'

通常我们建议直接设置成全网段访问,由其他层(region、安全组等)控制连通性。

不排除私有部署的客户对于安全性要求极高,要求设置指定网段访问,那么此时,就要查看一下实例是否存在于这个白名单中。

注意:MGR 中的节点,每个白名单配置都可能不一样(强烈不建议!建议配置成一致的!),所以,要把集群中所有的节点都查一遍,避免出现后续问题。

常见错误:This member has more executed transactions than those present in the group.

出现场景:

    1. 有应用直连,往里写数据

    2. 有人误在从库上直接 *** 作

    3. 错误的恢复手段:这个最为常见

解决办法:

    1. 查看哪些数据被错误应用,进行相应处理

    2. 找到最后同步的 GTID 位点

    3. reset master

    4. 设置最后 gtid_purged 为要继续同步的 GTID 位点

常见错误:Member was expelled from the group due to network failures, changing member status to ERROR

出现场景:网络延迟

解决方法:等待网络恢复正常后,重新加入集群即可

常见错误:the master has purged binary logs containing GTIDs that the slave requires

出现场景:从库脱离群组时间太长,无法通过已有的 binlog 进行恢复了

解决方法:重做数据(mysqldump 或 xtrabackup)后,加入群组

select TABLE_SCHEMA, TABLE_NAME from information_schema.tables where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys') and  TABLE_NAME not in (select  table_name from information_schema.TABLE_CONSTRAINTS  where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys') and CONSTRAINT_TYPE = 'PRIMARY KEY')

select TABLE_SCHEMA, TABLE_NAME from information_schema.tables where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys')  and engine <>'InnoDB'

本文作者、编辑:刘桐烔

欢迎大家点赞、在看、关注~


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8532931.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-17
下一篇 2023-04-17

发表评论

登录后才能评论

评论列表(0条)

保存