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音频采集声音不连续问题分析与解决办法经验总结
最近广州大雨不断,并且多数无前兆,突然就来场大雨,给同学们降降温,说来本也是好事,但有时候下的真不是时候,最近这段时间都是即将下班了,大雨就来了,昨晚快下班前又出现了大雨,北方人总爱忘带雨伞,这不就被 ...
随机推荐
- 关于『HTML』:第三弹
关于『HTML』:第三弹 建议缩放90%食用 盼望着, 盼望着, 第三弹来了, HTML基础系列完结了!! 一切都像刚睡醒的样子(包括我), 欣欣然张开了眼(我没有) 敬请期待Markdown语法系列 ...
- C#获取PLC信息 （KepServer）二
具体应用呢,不多说了,上代码,取长补短就是原创 using OPCAutomation; using System; using System.Collections.Generic; using S ...
- String、StringBuilder、StringBuffer——JavaSE基础
String.StringBuilder.StringBuffer String不可变 StringBuilder与StringBuffer均可变 StringBuilder线程不安全,效率高,常用 ...
- SpringBoot官方支持任务调度框架，轻量级用起来也挺香！
大家好,我是二哥呀.定时任务的应用场景其实蛮常见的,比如说: 数据备份 订单未支付则自动取消 定时爬取数据 定时推送信息 定时发布文章 等等(想不出来了,只能等等来凑,,反正只要等的都需要定时,怎么样 ...
- Spring基础只是—AOP的概念介绍
Spring容器包含两个重要的特性:面向切面编程(AOP)和控制反转(IOC).面向切面编程是面向对象(OOP)的一种补充,在面向对象编程的过程中编程针对的目标是一个个对象,而面向切面编程中编程针对的 ...
- 3D还原货拉拉女孩身亡真相，这一环值得反思！
货拉拉女孩跳车身亡的消息,让人惋惜又震惊.司机多次偏离原始路线,女孩最终选择跳车,结果不幸身亡. 货拉拉女孩跳车真相被3D还原 有人质疑平台监管不力,造成如此惨剧,有人吐槽企业压榨员工,司机绕路是不得 ...
- 利用XtraDiagram.DiagramControl进行流程图形的绘制和控制
DevExpress提供了一个比较强大的图形绘制工具,可以用于绘制各种图形,如流程图.组织机构图等等,本篇随笔介绍XtraDiagram.DiagramControl的使用,以及利用代码对其属性进行控 ...
- word processing in nlp with tensorflow
Preprocessing Tokenizer source code:https://github.com/keras-team/keras-preprocessing/blob/master/ke ...
- 利用kubernetes资源锁完成自己的HA应用
Backgroud 前一章中,对kubernetes的选举原理进行了深度剖析,下面就通过一个example来实现一个,利用kubernetes提供的选举机制完成的高可用应用. 对于此章需要提前对一些概 ...
- 一个紧张刺激的聊天器，要不要进来看看（Python UDP网络模型）
先来哔哔两句:(https://jq.qq.com/?_wv=1027&k=QgGWqAVF) 互联网的本质是什么?其实就是信息的交换.那么如何将自己的信息发送到其他人的电脑上呢?那就需要借助 ...