暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / mysql gtid_executed事务ID不连续的问题

mysql gtid_executed事务ID不连续的问题

原创 lair 2022-09-12
271

1、问题描述

在做MGR测试的时候偶尔遇到gtid_executed事务ID不连续的问题，但是并不影响数据库的正常运行。现象如下


  1. GreatDB Cluster[sysbench]> select @@gtid_executed;

  2. +-----------------------------------------------------------------+

  3. | @@gtid_executed                                                 |

  4. +-----------------------------------------------------------------+

  5. | 5cd1a64d-7358-11ec-b349-080027fa2d35:1-1286:2052-2290:3052-3277 |

  6. +-----------------------------------------------------------------+

  7. 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位平台为1~4294967295，64位平台为1~9223372036854775807，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


  1. GreatDB Cluster[(none)]> set persist group_replication_gtid_assignment_block_size=1000;

  2. Query OK, 0 rows affected (0.00 sec)

  3.  

  4. GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=on;

  5. Query OK, 0 rows affected (0.00 sec)

  6.  

  7. GreatDB Cluster[(none)]> start group_replication;

  8. Query OK, 0 rows affected (2.45 sec)

  9.  

  10. GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=off;

  11. Query OK, 0 rows affected (0.00 sec)
复制

把82切换为主节点然后通过sysbench模拟业务


  1. GreatDB Cluster[sysbench]> select @@gtid_executed;

  2. +---------------------------------------------+

  3. | @@gtid_executed                             |

  4. +---------------------------------------------+

  5. | 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5445 |

  6. +---------------------------------------------+

  7. 1 row in set (0.00 sec)

  8.  

  9. GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;

  10. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  11. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

  12. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  13. | group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 |        4444 | ONLINE       | PRIMARY     | 8.0.25         |

  14. | group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 |        4444 | ONLINE       | SECONDARY   | 8.0.25         |

  15. | group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 |        4444 | ONLINE       | SECONDARY   | 8.0.25         |

  16. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  17. 3 rows in set (0.00 sec)

  18.  

  19. GreatDB Cluster[sysbench]> SELECT group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155');

  20. +--------------------------------------------------------------------------+

  21. | group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155') |

  22. +--------------------------------------------------------------------------+

  23. | Primary server switched to: cf520b3b-7354-11ec-b785-08002792d155         |

  24. +--------------------------------------------------------------------------+

  25. 1 row in set (1.38 sec)

  26.  

  27. GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;

  28. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  29. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

  30. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  31. | group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 |        4444 | ONLINE       | SECONDARY   | 8.0.25         |

  32. | group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 |        4444 | ONLINE       | PRIMARY     | 8.0.25         |

  33. | group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 |        4444 | ONLINE       | SECONDARY   | 8.0.25         |

  34. +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

  35. 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


  1. GreatDB Cluster[sysbench]> select @@gtid_executed;

  2. +-------------------------------------------------------+

  3. | @@gtid_executed                                       |

  4. +-------------------------------------------------------+

  5. | 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5445:6053-6268 |

  6. +-------------------------------------------------------+

  7. 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恢复连续


  1. GreatDB Cluster[sysbench]> select @@gtid_executed;

  2. +-------------------------------------------------------+

  3. | @@gtid_executed                                       |

  4. +-------------------------------------------------------+

  5. | 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5451:6053-6659 |

  6. +-------------------------------------------------------+

  7. 1 row in set (0.00 sec)

  8.  

  9. GreatDB Cluster[sysbench]> select @@gtid_executed;

  10. +---------------------------------------------+

  11. | @@gtid_executed                             |

  12. +---------------------------------------------+

  13. | 5cd1a64d-7358-11ec-b349-080027fa2d35:1-6665 |

  14. +---------------------------------------------+

  15. 1 row in set (0.01 sec)
复制

解析binlog，分析gtid生成时间


  1. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6268'/*!*/;

  2. # at 173167217

  3. #220112 15:12:29 server id 1  end_log_pos 173167287     Query   thread_id=19    exec_time=0     error_code=0

  4.  

  5. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6269'/*!*/;

  6. # at 173169472

  7. #220112 15:14:29 server id 1  end_log_pos 173169542     Query   thread_id=19    exec_time=1     error_code=0

  8.  

  9. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6659'/*!*/;

  10. # at 174048922

  11. #220112 15:14:50 server id 1  end_log_pos 174048992     Query   thread_id=19    exec_time=0     error_code=0

  12.  

  13. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:6660'/*!*/;

  14. # at 175419962

  15. #220112 15:15:04 server id 1  end_log_pos 175420032     Query   thread_id=19    exec_time=0     error_code=0

  16.  

  17.  

  18. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:5445'/*!*/;

  19. # at 172680137

  20. #220112 15:06:15 server id 1  end_log_pos 172680207     Query   thread_id=19    

  21.  

  22.  

  23.  

  24. SET @@SESSION.GTID_NEXT= '5cd1a64d-7358-11ec-b349-080027fa2d35:5446'/*!*/;

  25. # at 174051177

  26. #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 :)

mysql
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论

相关阅读

【MySQL 30周年庆】MySQL 8.0 OCP考试限时免费！教你免费领考券
墨天轮小教习
508次阅读
2025-04-25 18:53:11
墨天轮个人数说知识点合集
JiekeXu
446次阅读
2025-04-01 15:56:03
MySQL 30 周年庆！MySQL 8.4 认证免费考！这次是认真的。。。
严少安
427次阅读
2025-04-25 15:30:58
MySQL数据库当前和历史事务分析
听见风的声音
426次阅读
2025-04-01 08:47:17
MySQL 生产实践-Update 二级索引导致的性能问题排查
chengang
390次阅读
2025-03-28 16:28:31
【活动】分享你的压箱底干货文档，三篇解锁进阶奖励！
墨天轮编辑部
365次阅读
2025-04-17 17:02:24
MySQL 9.3 正式 GA，我却大失所望，新特性亮点与隐忧并存？
JiekeXu
357次阅读
2025-04-15 23:49:58
3月“墨力原创作者计划”获奖名单公布
墨天轮编辑部
332次阅读
2025-04-15 14:48:05
openHalo问世，全球首款基于PostgreSQL兼容MySQL协议的国产开源数据库
严少安
305次阅读
2025-04-07 12:14:29
记录MySQL数据库的一些奇怪的迁移需求！
陈举超
201次阅读
2025-04-15 15:27:53