Changes in GreatSQL 5.7.36 (2022-4-7)
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主从节点因为大事务等原因延迟超过阈值时,就会触发流控机制。
System Variable Name | group_replication_flow_control_replay_lag_behind |
---|---|
Variable Scope | global |
Dynamic Variable | YES |
Permitted Values | [0 ~ ULONG_MAX] |
Default | 600 |
Description | 单位:秒。 用于控制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毫秒)。
System Variable Name | group_replication_request_time_threshold |
---|---|
Variable Scope | Global |
Dynamic Variable | YES |
Permitted Values | [0 ~ 100000000] |
Default | 0 |
Description | 单位:微秒。 设置阈值,当一个事务的MGR层网络开销超过该阈值时,会在error log中输出一条记录。 设置为0时,表示不启用。 当怀疑可能因为MGR通信耗时过久成为事务性能瓶颈时,再开启,平时不建议开启。 |
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'
System Variable Name | group_replication_transaction_size_limit |
---|---|
Variable Scope | Global |
Dynamic Variable | YES |
Permitted Values | [0 ~ 150000000] |
Default | 150000000 |
Description | 单位:Bytes。 设置大事务阈值,当一个MGR事务超过该阈值时,会在error log中输出一条记录 |
2.稳定性提升
- 修复了在异常情况下(节点崩溃,关闭节点,网络分区)的剧烈性能抖动问题。
- 提升数个大事务造成的长时间阻塞的问题。
3.性能提升
- 重新设计事务认证队列清理算法。MySQL社区版本中,对事务认证队列清理时采用了类似全表扫描的算法,清理效率较低,性能抖动较大。在GreatSQL版本中,对事务认证队列增加了类似索引机制,并控制每次清理的时间,可以有效解决清理效率低、性能抖动大的问题。
- 提升了Secondary节点上大事务并发应用回放的速度。
- 增加xcom cache条目,提升了在网络延迟较大或事务应用较慢场景下的性能。
4.bug修复
- 修复了在启用dns或hostname的情况下,bind意外失败问题。
- 修复了协程调度不合理的问题,该问题可能会造成在大事务时系统错误判断为网络错误。
- 修复了新加入节点在追paxos数据时,由于write超时导致连接提前关闭的问题。
- 修复了recovering节点被中途停止导致的数据异常问题。
- 修复了多主多写模式中,个别情况下可能丢数据的问题。
- 修复了在某些特殊场景下,多个节点同时启动一直处于recovering的状态
- 修复了applier线程在特殊场景下的诡异问题。
- 修复了在高并发情况下由于创建线程失败导致的死循环问题。
- 修复了某一个从节点hang住导致整个集群被拖垮的问题。
- 修复了单机部署多个节点场景下,tcp self connect导致的诡异问题。
- 修复了同时多个异常导致的视图问题。
- 修复了5个及以上节点数量同时重启导致的视图问题(某一个节点会一直处于recovering状态)。
- 修复了在某些场景下同时添加节点失败的问题。
- 修复了在特殊场景下组视图异常的问题。
Enjoy GreatSQL
文章推荐:
面向金融级应用的GreatSQL正式开源
https://mp.weixin.qq.com/s/cI_wPKQJuXItVWpOx_yNTg
Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qcn0lmsMoLtaGO9hbpnhVg
MGR及GreatSQL资源汇总
https://mp.weixin.qq.com/s/qXMct_pOVN5FGoLsXSD0MA
GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA
在Linux下源码编译安装GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZZOWKqSaGSy-mpD2GdNcA
关于 GreatSQL
GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。
Gitee:
https://gitee.com/GreatSQL/GreatSQL
GitHub:
https://github.com/GreatSQL/GreatSQL
Bilibili:
https://space.bilibili.com/1363850082/video
微信&QQ群:
可搜索添加GreatSQL社区助手微信好友,发送验证信息“加群”加入GreatSQL/MGR交流微信群
QQ群:533341697
微信小助手:wanlidbc
本文由博客一文多发平台 OpenWrite 发布!
Changes in GreatSQL 5.7.36 (2022-4-7)的更多相关文章
- Hadoop 二次排序
需求 求每年的最高气温,年份升序,温度求最高 数据源内容如下 temperature.txt 2004 49 1981 -22 1981 -31 1965 -47 2027 -2 1964 6 203 ...
- 深入理解hadoop之排序
MapReduce的排序是默认按照Key排序的,也就是说输出的时候,key会按照大小或字典顺序来输出,比如一个简单的wordcount,出现的结果也会是左侧的字母按照字典顺序排列.下面我们主要聊聊面试 ...
- Linux系统搭建私有CA证书服务器
一.CA简介 CA是什么?CA是Certificate Authority的简写,从字面意思翻译过来是凭证管理中心,认证授权.它有点类似我们生活中的身份证颁发机构,这里的CA就相当于生活中颁发身份证的 ...
- py3nvml实现GPU相关信息读取
技术背景 随着模型运算量的增长和硬件技术的发展,使用GPU来完成各种任务的计算已经渐渐成为算法实现的主流手段.而对于运行期间的一些GPU的占用,比如每一步的显存使用率等诸如此类的信息,就需要一些比较细 ...
- 检查oracle是否是rac
采样rac集群 [root@shfpdb02 disks]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 ( ...
- jvm造轮子
博客内容来源于 刘欣老师的课程,刘欣老师的公众号 码农翻身 博客内容来源于 Java虚拟机规范(JavaSE7) 博客内容的源码 https://gitee.com/zumengjie/litejvm ...
- 拒绝蛮力,高效查看Linux日志文件!
原创:扣钉日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处. 简介 日常分析问题时,会频繁地查看分析日志,但如果蛮力去查看日志,耗时费力还不一定有效果,因此我总结了在Linux常用的 ...
- Oracle:ORA-39006、ORA-39213解决办法
执行Oracle数据库导入,遇到报错ORA-39006: internal error.ORA-39213: Metadata processing is not available.这还是第一次遇到 ...
- 36氪新风向 | 三个月估值普涨三倍,你未来的RPA机器人同事正在路上
http://www.sohu.com/a/320208242_114778 2019 年 4 月,关注 RPA 赛道的投资人 Kevin(化名)就发现,仅仅过了一个春节,自己所在的早期基金已经投不起 ...
随机推荐
- Android.mk编译App源码
在Andriod源码环境编译APP主要考虑如何引入第三方jar包和arr包的问题,初次尝试,步步是坑,这里给出一个模板: LOCAL_PATH := $(call my-dir) include $( ...
- Fail2ban 配置详解 动作配置
### # 包含配置 ### [INCLUDES] before = iptables-common.conf ### # 定义动作 ### [Definition] actionstart = &l ...
- Java 接口返回值集合防止空指针
接口 返回值为一个集合 public interface UserSearchService{ List<User> listUser(); } 接口实现 public List<U ...
- Docker容器手动安装mysql(国内镜像)
Docker手动安装mysql 1.创建centos镜像的容器 [root@localhost Tools]# docker run -i -d -h zabbix --name zabbix -p ...
- Apache Shiro反序列化漏洞(Shiro550)
1.漏洞原理: Shiro 是 Java 的一个安全框架,执行身份验证.授权.密码.会话管理 shiro默认使用了CookieRememberMeManager,其处理cookie的流程是:得到rem ...
- flowable如何适配国产数据库达梦
前言 flowable6.4.1流程引擎官方支持的数据库有:MySQL.hsql.Oracle.DB2 .postgres.SQL Server.H2.对于其他类型的数据库如何支持,尤其是国产数据库的 ...
- .NET 处理[未能为 SSLTLS 安全通道建立信任关系]问题
更新记录 2022年4月16日本文迁移自Panda666原博客,原发布时间:2021年7月16日. 在.NET的开发过程中,发现[基础连接已经关闭: 未能为 SSL/TLS 安全通道建立信任关系]问题 ...
- 【高并发】通过ThreadPoolExecutor类的源码深度解析线程池执行任务的核心流程
核心逻辑概述 ThreadPoolExecutor是Java线程池中最核心的类之一,它能够保证线程池按照正常的业务逻辑执行任务,并通过原子方式更新线程池每个阶段的状态. ThreadPoolExecu ...
- BUUCTF-刷新过的图片
刷新过的图片 刷新在MISC中比较特殊,一般是指F5隐写方式 直接使用工具提取出来,发现生成的是Pk开头的,应该是zip格式 使用16进制确认了是ZIP,将生成的output.txt改为output. ...
- 关于个人全栈项目【臻美IT】博客类出现的问题以及解决方法
每做一个项目,要记得写下心得哦,别偷懒啊!先上网址:https://www.maomin.club/ 这个项目属于博客类的,因为百度审核的问题就大体做了下,就当来练练手,里面文章链接的是CSDN的博客 ...