[toc]

1.新增个性

1.2 新增MGR角色列

在MySQL 5.7中，查问 performance_schema.replication_group_members 时，没有 MEMBER_ROLE 这个列，这很不便于疾速查看哪个节点是Primary Node。

在GreatSQL中，减少了这个列，查看节点角色更便当了，对一些中间件反对也更敌对。

mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| group_replication_applier | 4c21e81e-953f-11ec-98da-d08e7908bcb1 | 127.0.0.1   |        3308 | ONLINE       | SECONDARY   || group_replication_applier | b5e398ac-8e33-11ec-a6cd-d08e7908bcb1 | 127.0.0.1   |        3306 | ONLINE       | PRIMARY     || group_replication_applier | b61e7075-8e33-11ec-a5e3-d08e7908bcb1 | 127.0.0.1   |        3307 | ONLINE       | SECONDARY   |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+

1.2 采纳全新的流控机制

原生的流控算法有较大缺点，触发流控阈值后，会有短暂的流控进展动作，之后持续放行事务，这会造成1秒的性能抖动，且没有真正起到继续流控的作用。

在GreatSQL中，从新设计了流控算法，减少主从延迟时间来计算流控阈值，并且同时思考了大事务处理和主从节点的同步，流控粒度更粗疏，不会呈现MySQL社区版本的1秒小抖动问题。

新增选项 group_replication_flow_control_replay_lag_behind 用于管制MGR主从节点复制提早阈值，当MGR主从节点因为大事务等起因提早超过阈值时，就会触发流控机制。

该选项默认为600秒，可在线动静批改，例如：

mysql> SET GLOBAL group_replication_flow_control_replay_lag_behind = 600;

失常状况下，该参数无需调整。

1.3 新增MGR网络开销阈值

新增相应选项 group_replication_request_time_threshold。

在MGR构造中，一个事务的开销蕴含网络层以及本地资源（例如CPU、磁盘I/O等）开销，GreatSQL针对MGR的网络层开销进行了多项优化工作，因而在网络层的开销通常不会成为瓶颈。

当事务响应较慢想要剖析性能瓶颈时，能够先确定是网络层的开销还是本地性能瓶颈导致的。通过设置选项 group_replication_request_time_threshold 即可记录超过阈值的事件，便于进一步剖析。输入的内容记录在error log中，例如：

2022-03-04T09:45:34.602093+08:00 128 [Note] Plugin group_replication reported: 'MGR request time:33775'

示意过后这个事务在MGR层的网络开销耗时33.775毫秒，再去查看那个时段的网络监控，剖析网络提早较大的起因。

选项 group_replication_request_time_threshold 单位是微秒，默认值是0，最小值0，最大值100000000，倡议值20000（即20毫秒）。

1.4 调整MGR大事务限度

调整MGR事务限度选项 group_replication_transaction_size_limit，其默认值为150000000（同时也是最大值）。

在MySQL 5.7中，MGR事务没有进行分片解决，执行大事务很容易造成超时（并重复重发事务数据），最终导致节点报错并退出集群。

在GreatSQL 5.7中，针对该问题进行优化，并设置事务下限，超过该下限事务会失败回滚，但节点不会再退出集群。

留神，这是硬限度，即使将其设置为0，也会主动调整成150000000。

mysql> set global group_replication_transaction_size_limit = 150000001;Query OK, 0 rows affected, 1 warning (0.00 sec)-- 提醒被重置了mysql> show warnings;+---------+------+-------------------------------------------------------------------------+| Level   | Code | Message                                                                 |+---------+------+-------------------------------------------------------------------------+| Warning | 1292 | Truncated incorrect group_replication_transaction_si value: '150000001' |+---------+------+-------------------------------------------------------------------------+1 row in set (0.00 sec)mysql> set global group_replication_transaction_size_limit=0;Query OK, 0 rows affected (0.00 sec)-- 尽管没有error也没warning，但也被重置了mysql> select @@global.group_replication_transaction_size_limit;+---------------------------------------------------+| @@global.group_replication_transaction_size_limit |+---------------------------------------------------+|                                         150000000 |+---------------------------------------------------+

当执行一个超限的大事务时，会报告上面的谬误：

ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.

以测试工具sysbench生成的表为例，事务一次可批量执行的数据行下限约73.2万条记录：

mysql> insert into t1 select * from sbtest1 limit 732000;Query OK, 732000 rows affected (16.07 sec)Records: 732000  Duplicates: 0  Warnings: 0mysql> insert into t1 select * from sbtest1limit 733000;ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.

如果大事务能执行胜利，也会记录相似上面的日志，告知该事务的字节数：

[Note] Plugin group_replication reported: 'large transaction size:149856412'

2.稳定性晋升

1. 修复了在异常情况下（节点解体，敞开节点，网络分区）的激烈性能抖动问题。
2. 晋升数个大事务造成的长时间阻塞的问题。

3.性能晋升

1. 从新设计事务认证队列清理算法。MySQL社区版本中，对事务认证队列清理时采纳了相似全表扫描的算法，清理效率较低，性能抖动较大。在GreatSQL版本中，对事务认证队列减少了相似索引机制，并管制每次清理的工夫，能够无效解决清理效率低、性能抖动大的问题。
2. 晋升了Secondary节点上大事务并发利用回放的速度。
3. 减少xcom cache条目，晋升了在网络提早较大或事务利用较慢场景下的性能。

4.bug修复

1. 修复了在启用dns或hostname的状况下，bind意外失败问题。
2. 修复了协程调度不合理的问题，该问题可能会造成在大事务时零碎错误判断为网络谬误。
3. 修复了新退出节点在追paxos数据时，因为write超时导致连贯提前敞开的问题。
4. 修复了recovering节点被中途进行导致的数据异样问题。
5. 修复了多主多写模式中，个别情况下可能丢数据的问题。
6. 修复了在某些非凡场景下，多个节点同时启动始终处于recovering的状态
7. 修复了applier线程在非凡场景下的诡异问题。
8. 修复了在高并发状况下因为创立线程失败导致的死循环问题。
9. 修复了某一个从节点hang住导致整个集群被拖垮的问题。
10. 修复了单机部署多个节点场景下，tcp self connect导致的诡异问题。
11. 修复了同时多个异样导致的视图问题。
12. 修复了5个及以上节点数量同时重启导致的视图问题（某一个节点会始终处于recovering状态）。
13. 修复了在某些场景下同时增加节点失败的问题。
14. 修复了在非凡场景下组视图异样的问题。

Enjoy GreatSQL :)

文章举荐：

面向金融级利用的GreatSQL正式开源
https://mp.weixin.qq.com/s/cI...

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc...

MGR及GreatSQL资源汇总
https://mp.weixin.qq.com/s/qX...

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6...

在Linux下源码编译装置GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ...

# 对于 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 公布！