技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现

欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答
  • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
MySQL 8.0.26下MGR表现如何?用实测数据说话。
此外,MySQL 8.0.26还存在一个严重缺陷。
MySQL 8.0.26发布差不多两个月了,一直还没对它进行测评,看到release notes中涉及到几个MGR相关的Bug fixed,最近抽空对其简单测试一番,下面说说结果吧。
本文后半段还会爆出MySQL 8.0.26的一个严重缺陷。
本次测试选用sysbench的mix-load方案(感谢楼方鑫老师的分享):
require("oltp_common")local runtype = 0; function prepare_statements() -- use 1 query per event, rather than sysbench.opt.point_selects which -- defaults to 10 in other OLTP scripts sysbench.opt.point_selects=1runtype = (10 * sysbench.tid + 10) / sysbench.opt.threadsif runtype <= 6 then prepare_point_selects() else prepare_non_index_updates() end endfunction event(thread_id) if runtype <= 6 then execute_point_selects() else execute_non_index_updates() end end

下面是压测相关的几个指标参数:
  • --tables=10
  • --table_size=100000
  • --threads=16
  • --report-interval=1
下面是InnoDB & MGR相关的几个主要参数选项值:
innodb_buffer_pool_size = 256Mslave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 64 binlog_transaction_dependency_tracking = WRITESET slave_preserve_commit_order = 1 slave_checkpoint_period = 2group_replication_flow_control_mode = "DISABLED"

备注:由于测试机配置一般,所以压测的数据量并不大,并发也不高。
接下来针对 group_replication_consistency 几个不同可选项,我拿GreatSQL 8.0.25-15 和 MySQL 8.0.26进行对比,主要关注tps和latency数据。
【技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现】1. group_replication_consistency=EVENTUAL
技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
文章图片

从上面的几个测试数据可以看到:
1.MySQL 8.0.26的tps还是很不平稳,波动很大。
2.MySQL 8.0.26的latency也是波动很大。
另外,从测试的直观感受来看,在MySQL 8.0.26以前的版本中存在的几个问题略有改善:
1.被kill后的SECONDARY节点重新加回集群,分布式事务恢复较快(快辄20-30秒左右),不像以往要很久(最少1-2分钟)。
2.把SECONDARY节点kill后,集群tps波动的时长变短了,之前大概需要20-30秒,现在大概10-20秒。
3.把SECONDARY节点kill后,集群还是大约要20多秒才能将其踢出,这个没改善。
4.磁盘空间满之后会导致MGR事务被阻塞,在8.0.26里依然会阻塞事务,时间太久就没及时处理的话,还会因为待认证事务堆积等原因导致mysqld进程被oom killed,这个算是更严重了(BUG#104979),后面我再整理文章。
接下来说说MySQL 8.0.26的严重问题吧(BUG#104980)。
复现方案:
1.设置 group_replication_consistency = BEFORE_AND_AFTER | AFTER(二选一,其余模式暂未出现问题)。
2.启动sysbench对MGR集群进行持续压力测试。
3.压测过程中,随机kill某个SECONDARY节点。
4.经多次重试,会有相当大概率出现该SECONDARY节点无法重新加回集群的问题。报错信息类似下面这样:
[ERROR] [MY-013309] [Repl] Plugin group_replication reported: 'Transaction '2:39976870' does not exist on Group Replication consistency manager while receiving remote transaction prepare.' [ERROR] [MY-011452] [Repl] Plugin group_replication reported: 'Fatal error during execution on the Applier process of Group Replication. The server will now leave the group.' [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'"

同样的测试,在GreatSQL 8.0.25中未出现,还是相当给力的呀。
所幸的是,一般很少选用AFTER或BEFORE_AND_AFTER模式,所以能碰到这个BUG的人不会太多才对。
再报告个小问题(BUG#104974),在线设置 group_replication_consistency 选项值时,如果设置为 BEFORE,则必须加引号才可以,否则会报错,其他几个模式则没问题:
mysql>set global group_replication_consistency=EVENTUAL; Query OK, 0 rows affected (0.00 sec)mysql>set global group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER; Query OK, 0 rows affected (0.00 sec)mysql>set global group_replication_consistency=BEFORE; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'BEFORE' at line 1mysql>set global group_replication_consistency='BEFORE'; Query OK, 0 rows affected (0.00 sec)mysql>set global group_replication_consistency=AFTER; Query OK, 0 rows affected (0.00 sec)mysql>set global group_replication_consistency= BEFORE_AND_AFTER; Query OK, 0 rows affected (0.00 sec)

Enjoy GreatSQL :)
文章推荐: GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6...
万答#12,MGR整个集群挂掉后,如何才能自动选主,不用手动干预
https://mp.weixin.qq.com/s/07...
『2021数据技术嘉年华·ON LINE』:《MySQL高可用架构演进及实践》
https://mp.weixin.qq.com/s/u7...
一条sql语句慢在哪之抓包分析
https://mp.weixin.qq.com/s/AY...
万答#15,都有哪些情况可能导致MGR服务无法启动
https://mp.weixin.qq.com/s/in...
技术分享 | 为什么MGR一致性模式不推荐AFTER
https://mp.weixin.qq.com/s/rN...
关于 GreatSQL GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。
Gitee:
https://gitee.com/GreatSQL/Gr...
GitHub:
https://github.com/GreatSQL/G...
Bilibili:
https://space.bilibili.com/13...
微信&QQ群:
可搜索添加GreatSQL社区助手微信好友,发送验证信息“加群”加入GreatSQL/MGR交流微信群
QQ群:533341697
微信小助手:wanlidbc
本文由博客一文多发平台 OpenWrite 发布!

    推荐阅读