简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现-蒲公英云

本文首发于 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

2. group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER

3. group_replication_consistency=BEFORE

4. group_replication_consistency=AFTER

5. group_replication_consistency=BEFORE_AND_AFTER

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

MySQL 8.0.26的tps还是很不平稳，波动很大。
MySQL 8.0.26的latency也是波动很大。

另外，从测试的直观感受来看，在MySQL 8.0.26以前的版本中存在的几个问题略有改善：

被kill后的SECONDARY节点重新加回集群，分布式事务恢复较快（快辄20-30秒左右），不像以往要很久（最少1-2分钟）。
把SECONDARY节点kill后，集群tps波动的时长变短了，之前大概需要20-30秒，现在大概10-20秒。
把SECONDARY节点kill后，集群还是大约要20多秒才能将其踢出，这个没改善。
磁盘空间满之后会导致MGR事务被阻塞，在8.0.26里依然会阻塞事务，时间太久就没及时处理的话，还会因为待认证事务堆积等原因导致mysqld进程被oom killed，这个算是更严重了（BUG#104979），后面我再整理文章。

接下来说说MySQL 8.0.26的严重问题吧（BUG#104980）。

复现方案：

设置 group_replication_consistency = BEFORE_AND_AFTER | AFTER（二选一，其余模式暂未出现问题）。
启动sysbench对MGR集群进行持续压力测试。
压测过程中，随机kill某个SECONDARY节点。
经多次重试，会有相当大概率出现该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)