乐趣区

关于mysql:技术分享-简单测试MySQL-8026-vs-GreatSQL-8025的MGR稳定性表现

jiezi

欢送来到 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=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

从下面的几个测试数据能够看到：

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 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 公布！

退出移动版