MGR的gtid_executed不连续的问题分析
- GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
1、问题描述
在做MGR测试的时候偶尔遇到gtid_executed事务ID不连续的问题，但是并不影响数据库的正常运行。现象如下
GreatDB Cluster[sysbench]> select @@gtid_executed;
+-----------------------------------------------------------------+
| @@gtid_executed |
+-----------------------------------------------------------------+
| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-1286:2052-2290:3052-3277 |
+-----------------------------------------------------------------+
1 row in set (0.00 sec)
2、确认原因
查看官方文档发现以下参数：
group_replication_gtid_assignment_block_size
以下是对官方文档的翻译和理解
group_replication_gtid_assignment_block_size为每个成员保留的连续GTID数。每个成员从中进行消耗，并在其需要的时候获取更多的GTID数（类似于分布式事务中的全局序列，该系统变量设置的值表示每个成员每一次从全局序列中获取多大范围的连续数字范围来作为自身写事务的GTID号）。
该系统变量是组范围的配置设置，它必须在所有组成员上设置相同的值，在组复制运行时不允许修改，要使得修改值生效，需要完全重新引导组（使用系统变量group_replication_bootstrap_group= on来重新引导组）。
全局变量，动态变量，整型类型，默认值为1000000，取值范围：32位平台为14294967295，64位平台为19223372036854775807，MySQL 5.7.17版本引入。
官方文档地址：https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html
通过对文档了解到MGR会为每个实例节点分配一段连续的GTID值，所以怀疑是MGR发生了主从切换，从而导致GTID的事务ID不连续
2.1、复现问题
为方便测试修改group_replication_gtid_assignment_block_size为1000，并重启MGR
GreatDB Cluster[(none)]> set persist group_replication_gtid_assignment_block_size=1000;
Query OK, 0 rows affected (0.00 sec)
GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=on;
Query OK, 0 rows affected (0.00 sec)
GreatDB Cluster[(none)]> start group_replication;
Query OK, 0 rows affected (2.45 sec)
GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=off;
Query OK, 0 rows affected (0.00 sec)
把82切换为主节点然后通过sysbench模拟业务
GreatDB Cluster[sysbench]> select @@gtid_executed;
+---------------------------------------------+
| @@gtid_executed |
+---------------------------------------------+
| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5445 |
+---------------------------------------------+
1 row in set (0.00 sec)
GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 | 4444 | ONLINE | PRIMARY | 8.0.25 |
| group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 | 4444 | ONLINE | SECONDARY | 8.0.25 |
| group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 | 4444 | ONLINE | SECONDARY | 8.0.25 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
GreatDB Cluster[sysbench]> SELECT group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155');
+--------------------------------------------------------------------------+
| group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155') |
+--------------------------------------------------------------------------+
| Primary server switched to: cf520b3b-7354-11ec-b785-08002792d155 |
+--------------------------------------------------------------------------+
1 row in set (1.38 sec)
GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 | 4444 | ONLINE | SECONDARY | 8.0.25 |
| group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 | 4444 | ONLINE | PRIMARY | 8.0.25 |
| group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 | 4444 | ONLINE | SECONDARY | 8.0.25 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
模拟业务在新的主节点写业务
# sysbench ./oltp_read_write.lua --mysql-db=sysbench --mysql-host=172.16.50.82 --mysql-port=4444 --mysql-user=greatdb --mysql-password=greatdb --tables=3 --table_size=1000000 --report-interval=2 --threads=3 --db-driver=mysql --skip-trx=off --db-ps-mode=disable --create-secondary=off --time=10 --mysql-ignore-errors=9001,9002,9000,1062,8530,8532 run
检查当前的gtid_executed
GreatDB Cluster[sysbench]> select @@gtid_executed;
+-------------------------------------------------------+
| @@gtid_executed |
+-------------------------------------------------------+
| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5445:6053-6268 |
+-------------------------------------------------------+
1 row in set (0.00 sec)
2.2、空洞对实际使用的影响
模拟业务持续在82节点写业务
sysbench ./oltp_read_write.lua --mysql-db=sysbench --mysql-host=172.16.50.82 --mysql-port=4444 --mysql-user=greatdb --mysql-password=greatdb --tables=3 --table_size=1000000 --report-interval=2 --threads=3 --db-driver=mysql --skip-trx=off --db-ps-mode=disable --create-secondary=off --time=100 --mysql-ignore-errors=9001,9002,9000,1062,8530,8532 run
检查当前的gtid_executed,一段时间后gtid_executed恢复连续
GreatDB Cluster[sysbench]> select @@gtid_executed;
+-------------------------------------------------------+
| @@gtid_executed |
+-------------------------------------------------------+
| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5451:6053-6659 |
+-------------------------------------------------------+
1 row in set (0.00 sec)
GreatDB Cluster[sysbench]> select @@gtid_executed;
+---------------------------------------------+
| @@gtid_executed |
+---------------------------------------------+
| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-6665 |
+---------------------------------------------+
1 row in set (0.01 sec)
解析binlog，分析gtid生成时间
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6268'/*!*/;
# at 173167217
#220112 15:12:29 server id 1 end_log_pos 173167287 Query thread_id=19 exec_time=0 error_code=0
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6269'/*!*/;
# at 173169472
#220112 15:14:29 server id 1 end_log_pos 173169542 Query thread_id=19 exec_time=1 error_code=0
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6659'/*!*/;
# at 174048922
#220112 15:14:50 server id 1 end_log_pos 174048992 Query thread_id=19 exec_time=0 error_code=0
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6660'/*!*/;
# at 175419962
#220112 15:15:04 server id 1 end_log_pos 175420032 Query thread_id=19 exec_time=0 error_code=0
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:5445'/*!*/;
# at 172680137
#220112 15:06:15 server id 1 end_log_pos 172680207 Query thread_id=19
SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:5446'/*!*/;
# at 174051177
#220112 15:14:50 server id 1 end_log_pos 174051247 Query thread_id=19
分析发现事务id先从6268增长到6659然后开始补空洞补完后继续从6659开始增长
3、总结
group_replication_gtid_assignment_block_size为每个成员保留的连续GTID数。每个成员从中进行消耗，并在其需要的时候获取更多的GTID数（类似于分布式事务中的全局序列，该系统变量设置的值表示每个成员每一次从全局序列中获取多大范围的连续数字范围来作为自身写事务的GTID号）。
举个例子，集群中有2个节点，group_replication_gtid_assignment_block_size为1000，那么为节点A分配的Gtid_set为group_name:1-1000，节点B分配的Gtid_set为group_name:1001-2000。
则group_name:1-1000和group_name:1001-2000分别作为Gtid_set保存在member_gtids上。A节点的事务T1认证通过后，分配gtid为group_name:1，接着A节点事务T2分配group_name:2，然后B节点事务进入认证模块，认证通过后，为其分配group_name:1001，每分配一次gtid则gtids_assigned_in_blocks_counter增一。当发生主从切换时候，节点B会从1001开始记录gtid，所以会造成MGR的gtid_executed有时是不连续的多段，如aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2:1001-1005
若分配次数gtids_assigned_in_blocks_counter已达到gtid_assignment_block_size，则需要compute_group_available_gtid_intervals()重新计算。基于member_uuid找到该成员可用的gtid区间，若还没为该成员分配gtid，则调用reserve_gtid_block()进行分配。需要注意的是，reserve_gtid_block()是最多分配而不是一定分配block_size大小的gtid序列，是否等于block_size依赖于group_available_gtid_intervals的第一个可用的连续gtid序列大小是否等于或大于block_size。
Enjoy GreatSQL
文章推荐：
GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA
万答#12，MGR整个集群挂掉后，如何才能自动选主，不用手动干预
https://mp.weixin.qq.com/s/07o1poO44zwQIvaJNKEoPA
『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实践》
https://mp.weixin.qq.com/s/u7k99y6i7riq7ScYs7ySnA
一条sql语句慢在哪之抓包分析
https://mp.weixin.qq.com/s/AYibbzl860D90rOeyjB6IQ
万答#15，都有哪些情况可能导致MGR服务无法启动
https://mp.weixin.qq.com/s/inSGpd0Q_XIl2Mb-VsvNsA
技术分享 | 为什么MGR一致性模式不推荐AFTER
https://mp.weixin.qq.com/s/rNeq479RNsklY1BlfKOsYg
关于 GreatSQL
GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。
Gitee:
https://gitee.com/GreatSQL/GreatSQL
GitHub:
https://github.com/GreatSQL/GreatSQL
Bilibili：
https://space.bilibili.com/1363850082/video
微信&QQ群：
可搜索添加GreatSQL社区助手微信好友，发送验证信息“加群”加入GreatSQL/MGR交流微信群
QQ群：533341697
微信小助手：wanlidbc
本文由博客一文多发平台 OpenWrite 发布！
MGR的gtid_executed不连续的问题分析的更多相关文章
- 本田CB750型加速时发动机工作间歇
本田CB750型加速时发动机工作间歇 [故陣现象]近期以来,该车发动机工作无力,加速时发 动机工作不连续. [原因分析]起动发动机试验,发动机起动困难,怠速时 抖动严重,加速反应缓慢,工作间歇,声音沉 ...
- LPS UVA 11404 Palindromic Subsequence
题目传送门 题意:求LPS (Longest Palidromic Subsequence) 最长回文子序列.和回文串不同,子序列是可以不连续的. 分析:1. 推荐->还有一种写法是用了LCS的 ...
- MGR实现分析 - 成员管理与故障恢复实现
MySQL Group Replication(MGR)框架让MySQL具备了自动主从切换和故障恢复能力,举single primary(单主)模式为例,primary作为主节点对外提供读写服务,是唯 ...
- MySQL MGR实现分析 - 成员管理与故障恢复实现
此文已由作者温正湖授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. MySQL Group Replication(MGR)框架让MySQL具备了自动主从切换和故障恢复能力,举 ...
- 一个导致MGR数据混乱Bug的分析和修复
1.背景 MGR是个好东西,因为他从本质上解决了数据不一致的问题.不光是解决了问题,而且出自名门正派(Oracle的MySQL团队),对品质和后续的维护,我们是可以期待的. 但是在调研的过程中,发现有 ...
- MySQL MGR源码分析2 - 从start group_replication看MGR代码框架
此文已由作者温正湖授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 上一篇我们从方案层面讲解了MGR的成员管理和故障恢复.本篇从源码层面捋一捋,通过本篇介绍,除了能够了解如何将 ...
- 从源码分析 MGR 的新主选举算法
MGR 的新主选举算法,在节点版本一致的情况下,其实也挺简单的. 首先比较权重,权重越高,选为新主的优先级越高. 如果权重一致,则会进一步比较节点的 server_uuid.server_uuid 越 ...
- 从源码分析 MGR 的流控机制
Group Replication 是一种 Shared-Nothing 的架构,每个节点都会保留一份数据. 虽然支持多点写入,但实际上系统的吞吐量是由处理能力最弱的那个节点决定的. 如果各个节点的处 ...
- DirectShow音频采集声音不连续问题分析与解决办法经验总结
最近广州大雨不断,并且多数无前兆,突然就来场大雨,给同学们降降温,说来本也是好事,但有时候下的真不是时候,最近这段时间都是即将下班了,大雨就来了,昨晚快下班前又出现了大雨,北方人总爱忘带雨伞,这不就被 ...
随机推荐
- 使用MinIO搭建对象存储服务
1.MinIO是什么? MinIO 是一款高性能.分布式的对象存储系统. 它是一款软件产品, 可以100%的运行在标准硬件.即X86等低成本机器也能够很好的运行MinIO. MinIO与传统的存储和其 ...
- 每天一个 HTTP 状态码 205
205 Reset Content 205 Reset Content 表示服务器成功地处理了客户端的请求,要求客户端重置它发送请求时的文档视图.这个响应码跟 204 No Content 类似,也不 ...
- 爬虫Ⅱ:scrapy框架
爬虫Ⅱ:scrapy框架 step5: Scrapy框架初识 Scrapy框架的使用 pySpider 什么是框架: 就是一个具有很强通用性且集成了很多功能的项目模板(可以被应用在各种需求中) scr ...
- T1创世纪（原创）
创世纪 这是我的第一道原创题 题解: 这道题的核心算法是:加维度的最短路+贪心 状态:\(dis[i][j][t][a]\)表示在 \(t\) 时,到达 \((i,j)\) ,当前共造\(a\)只&q ...
- IDEA windows版本快捷键
使用本快捷键前,可以在idea使用下面方法确认版本! Ctrl 快捷键 介绍 Ctrl + F 在当前文件进行文本查找 (必备)Ctrl + R 在当前文件进行文本替换 (必备) Ctrl + Z 撤 ...
- MTK 平台sensor arch 介绍-hal
MTK 平台sensor arch 介绍-hal 一:整体框架 二:具体流程简介 AP-HAL: (1)init & control flow 我们以前文的originchannel 的 ac ...
- 『忘了再学』Shell基础 — 26、cut列提取命令
目录 1.cut命令说明 2.cut命令练习 (1)cut命令基本用法 (2)cut命令选取多列 (3)按字符来进行提取 (4)按指定分隔符进行截取数据 3.cut命令分隔符说明 1.cut命令说明 ...
- 干货合集│最好用的 python 库都在这
一.分词 - jieba 优秀的中文分词库,依靠中文词库,利用词库确定汉子之间关联的概率,形成分词结果 import jieba word = '伟大的中华人民共和国' jieba.cut(word) ...
- C语言- 基础数据结构和算法 - 09 栈的应用_中缀表达式转后缀表达式20220611
09 栈的应用_中缀表达式转后缀表达式20220611 听黑马程序员教程<基础数据结构和算法 (C版本)>, 照着老师所讲抄的, 视频地址https://www.bilibili.com/ ...
- 卸载office密钥
一.管理员身份运行命令提示行: 二.命令提示行上输入: cd C:\Program Files\Microsoft Office\Office16 弹出如下内容: C:\Program Files\M ...