[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: 0

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