简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现

Dear 丶 2022-09-12 02:58 220阅读 0赞

本文首发于 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=1
    
       runtype = (10 * sysbench.tid + 10) / sysbench.opt.threads
    
       if runtype <= 6 then
         prepare_point_selects()
       else
         prepare_non_index_updates()
       end
    end
    
    function 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 = 256M
    
    slave_parallel_type = LOGICAL_CLOCK
    slave_parallel_workers = 64
    binlog_transaction_dependency_tracking = WRITESET
    slave_preserve_commit_order = 1
    slave_checkpoint_period = 2
    
    group_replication_flow_control_mode = "DISABLED"

备注：由于测试机配置一般，所以压测的数据量并不大，并发也不高。

接下来针对 group\_replication\_consistency 几个不同可选项，我拿GreatSQL 8.0.25-15 和 MySQL 8.0.26进行对比，主要关注tps和latency数据。

**1. group\_replication\_consistency=EVENTUAL**

![e8e0d275dd6f19151031f27bf274512f.png][]

![14da72c3a1c60fd9d1a1e432d32f6745.png][]

**2. group\_replication\_consistency=BEFORE\_ON\_PRIMARY\_FAILOVER**

![677405837beee75ed4632837b0492fee.png][]

![f44af270f7fe306761c8f0d0ef1f67c9.png][]

**3. group\_replication\_consistency=BEFORE**

![3678684ce7da843c524ff7105500a4f5.png][]

![236b62920406e4c5e8d6a0f6bed78a2d.png][]

**4. group\_replication\_consistency=AFTER**

![34b1b47d0b9f32df32aa4ac0b20819a0.png][]

![bb75faf2792be0c869964aaef82481a7.png][]

**5. group\_replication\_consistency=BEFORE\_AND\_AFTER**

![6d6dfb2e1a231e0c47539597cd27e749.png][]

![4ee97fbd80f480d79ec22e19d2cc2cdc.png][]

从上面的几个测试数据可以看到：

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 1
    
    mysql>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正式开源][GreatSQL]  
    
 *  [Changes in GreatSQL 8.0.25 (2021-8-26)][Changes in GreatSQL 8.0.25 _2021-8-26]
 *  [一周碎碎念，2021.9.12，之前说的MGR课程上线啦][2021.9.12_MGR]
 *  [技术分享 | Update更新慢、死锁等问题的排查思路分享][_ Update]
 *  [MySQL分区表的一个性能BUG][MySQL_BUG]  
    
 *  [《叶问》36期，MySQL最多只能用到128个逻辑CPU，是真的吗][36_MySQL_128_CPU]
 *  [GreatSQL重磅特性，InnoDB并行并行查询优化测试][GreatSQL_InnoDB]  
    
 *  [在Linux下源码编译安装GreatSQL/MySQL][Linux_GreatSQL_MySQL]

--------------------

扫码加入GreatSQL/MGR交流**QQ群**

![e454886e994ece54de2fb640f5e400cc.png][]

点击文末“**阅读原文**”直达老叶专栏

[e8e0d275dd6f19151031f27bf274512f.png]: /images/20220828/d4af662cc9c64de1a340b09aca0af84b.png
[14da72c3a1c60fd9d1a1e432d32f6745.png]: /images/20220828/bc92607eaf8644d2a60d4df0fb911d0d.png
[677405837beee75ed4632837b0492fee.png]: /images/20220828/5418514a7a884d6ca451e8421526f08c.png
[f44af270f7fe306761c8f0d0ef1f67c9.png]: /images/20220828/48cdf88be8ee48448209ce27f4a7b82b.png
[3678684ce7da843c524ff7105500a4f5.png]: /images/20220828/61fbd5f815444474b45c9a7d59eab2d7.png
[236b62920406e4c5e8d6a0f6bed78a2d.png]: /images/20220828/20135d1abcac4ab7b4399325556a4067.png
[34b1b47d0b9f32df32aa4ac0b20819a0.png]: /images/20220828/e9683288ed184fe6b773a4977d4b1d87.png
[bb75faf2792be0c869964aaef82481a7.png]: /images/20220828/bd3f26c61f4d4d3180872eb058ca1239.png
[6d6dfb2e1a231e0c47539597cd27e749.png]: /images/20220828/ea301db60a9547fcb1cf68be2522a7ae.png
[4ee97fbd80f480d79ec22e19d2cc2cdc.png]: /images/20220828/32fbb7701a744895a34128e56aeb4034.png
[GreatSQL]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936538&idx=1&sn=3017d9d51ea875e8d8c7c39fa6a74b17&chksm=bd3b41f08a4cc8e6554acaf7beef741d446cca01321c3eb5b0e494c8603351c9b8ac993547c3&scene=21#wechat_redirect
[Changes in GreatSQL 8.0.25 _2021-8-26]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936538&idx=2&sn=fb72b35d16e78fcb2e83a4ee72b38ccb&chksm=bd3b41f08a4cc8e65e832accd50aa8c1d2df9d54d0a770fd8316099f3aa6ee58372ea99a1b11&scene=21#wechat_redirect
[2021.9.12_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936554&idx=1&sn=cc64211e88d16d8c2cc08b3b19061251&chksm=bd3b41c08a4cc8d6c23c8ba7aa423aaa7b40739c1ffbeaa0e5623fb85c255f8b59305313f3cb&scene=21#wechat_redirect
[_ Update]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936568&idx=1&sn=3b754f68139a8d2b6d6a47abc4214395&chksm=bd3b41d28a4cc8c4bcdc1693b1f44aaf87217511ba4707edba0c75f7cf33974b4c9bb7500e04&scene=21#wechat_redirect
[MySQL_BUG]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936562&idx=1&sn=f523224b95f39f26f5c048990c3c5889&chksm=bd3b41d88a4cc8ced18268fcd9fa5f2591bf1dafbc579b5e7ae1af3d89e4b011cc71e663cddf&scene=21#wechat_redirect
[36_MySQL_128_CPU]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936499&idx=1&sn=f2efa2f3ae920b74039b6a9afa820238&chksm=bd3b41198a4cc80f18e90a0ad1b5550efbf20791e9512cd6c43dec9a0689da0d54fab5754749&scene=21#wechat_redirect
[GreatSQL_InnoDB]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936494&idx=1&sn=d3f96046483d991f4fae46db3d2ee618&chksm=bd3b41048a4cc8127aa2e87146b35d610f57188971e3f5bcf587cb2ac2faecd5f192f9c72653&scene=21#wechat_redirect
[Linux_GreatSQL_MySQL]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653936221&idx=1&sn=27183d95857dabef6bdf0d7541c4da57&chksm=bd3b40378a4cc921828ecf10774787bbf268d693490acf8c151a2b5c830bac3658870e95b396&scene=21#wechat_redirect
[e454886e994ece54de2fb640f5e400cc.png]: /images/20220828/0a975d5eae944a86ae4cc1272aa3cb21.png