关于数据库:GreatSQL-803224-今日发布

• 1.新增个性
• • 1.1 SQL兼容性
  • 1.2 MGR
  • 1.3 性能优化
  • 1.4 平安
• 2.稳定性晋升
• 3.其余调整
• 4.bug修复
• 5.GreatSQL VS MySQL
• 6.GreatSQL Release Notes

GreatSQL 8.0.32-24版本公布，减少并行load data、（逻辑 & CLONE）备份加密、MGR读写节点可绑定动静VIP、Oracle兼容扩大、审计日志加强等重磅个性。

直播预报：GreatSQL 8.0.32-24发布会

直播工夫：2023.06.05 15:00 - 16:00

扫码预约发布会或点击下方浏览原文进行报名

0.我的项目信息

• 代码仓库：https://gitee.com/GreatSQL/GreatSQL
• 最新下载：https://gitee.com/GreatSQL/GreatSQL/releases/tag/GreatSQL-8.0...
• 我的项目文档：https://greatsql.cn/docs
• 我的项目官网：https://greatsql.cn

1.新增个性

1.1 SQL兼容性

在GreatSQL 8.0.32-24中，实现了多项SQL兼容性性能，包含数据类型扩大、SQL语法等超过20个兼容个性。

1.1.1 数据类型扩大

• CLOB
• VARCHAR2

1.1.2 SQL语法

• DATETIME 运算
• ROWNUM
• 子查问无别名
• EXPLAIN PLAN FOR

1.1.3 函数

• ADD_MONTHS()
• CAST()
• DECODE()
• INSTR()
• LENGTH()
• LENGTHB()
• MONTHS_BETWEEN()
• NVL()
• SUBSTRB()
• SYSDATE()
• TO_CHAR()
• TO_DATE()
• TO_NUMBER()
• TO_TIMESTAMP()
• TRANSLATE()
• TRUNC()
• SYS_GUID()

更多信息详见文档：GreatSQL中的SQL兼容性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.2 MGR

1.2.1 MGR内置动静VIP

在GreatSQL 8.0.32-24中，新增MGR读写节点反对绑定VIP（虚构IP）个性。利用该个性，使得MGR在单主模式下运行时，能自动识别读写节点并绑定VIP，反对利用端即可通过VIP对数据库发动读写申请，当读写节点角色发生变化时，VIP也会随之主动漂移并从新绑定，利用端无需批改VIP配置。

更多信息详见文档：GreatSQL中MGR反对内置vip个性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.2.2 新增applier queue批处理机制

新增相应选项 group_replication_applier_batch_size_threshold。当MGR中的并发事务太大，或者个别Secondary节点（磁盘I/O）性能较差时，可能会导致applier queue沉积越来越大，始终无奈及时跟上Primary节点。

这时候无效的方法就是让applier queue落地时采纳批量的形式，进步落盘效率。默认地，applier queue里的event是一一落盘的，这种形式效率很低。当applier queue超过 group_replication_applier_batch_size_threshold 设定的阈值时，就会触发批量落盘模式，每100个event批量落盘，就能大大提高落盘效率。

在生产环境中，选项 group_replication_applier_batch_size_threshold 值不要设置太小，倡议不低于10000。默认值 100000，最小值10（仅用于开发、测试环境），最大值100000000（基本上等于禁用）。一个大事务会蕴含很多个event，当该选项设置太低时，可能会导致一个事务中的event没方法及时落盘，会造成relay log不残缺，节点crash时，就须要从Primary节点从新读取binlog进行复原。

1.2.3 Xcom cache调配动态化

在MySQL 5.7里，Xcom cache size最大值1G，且不可动静调整。从MySQL 8.0开始，可对其动静调整。在 <= MySQL 8.0.20的版本中，最小值1G。在>= MySQL 8.0.21的版本中，最小值128M。

在MySQL中，是动静按需分配Xcom cache的，如果太多有闲暇，就开释；如果不够用，再动态分配更多内存，一次调配大略250000个cache item，很容易造成约150ms的响应提早。也就是说，会随着事务多少的变动而可能频繁产生响应提早。

在GreatSQL中，对Xcom cache采纳了动态化分配机制，即一开始就预调配约1GB内存用于Xcom cache，这能够防止后面提到的响应提早抖动危险，不过“副作用”是mysqld过程所占用的内存会比原来多，在内存特地缓和的服务器上不太适宜。

新增相应选项 group_replication_xcom_cache_mode 用于设置Xcom cache动态化初始大小：

1.2.4 其余优化

• 优化了孟子算法，使得无论是单主模式还是多主模式下，均有不同水平的性能晋升。
• 打消了杀节点过程场景下的性能抖动。
• 优化了退出节点时可能导致性能激烈抖动的问题。
• 优化手工选主机制，解决了长事务造成无奈选主的问题。
• 欠缺MGR中的外键束缚机制，升高或防止从节点报错退出MGR的危险。
• 晋升了Secondary节点上大事务并发利用回放的速度。
• 减少Xcom cache条目，晋升了在网络提早较大或事务利用较慢场景下的性能。
• 新增参数选项：group_replication_broadcast_gtid_executed_period 用于设置节点之间各自播送节点的gtid值的频率，单位为毫秒，默认为1000，最小200，最大60 000，配合新的事务认证队列清理算法，进行认证数据库的清理操作。收到所有节点的gtid后，就能够清理都执行结束的gtid的认证信息了。
• 新增参数选项：group_replication_flow_control_max_wait_time，用于设置每次触发流控时，流控期待的最大时长，默认为3600s，最大为86400s（1天）。

1.3 性能优化

1.3.1 并行load data

MySQL原生的load data采纳单线程读取本地文件（或收取client传来的网络数据包），逐行获取内容后再插入数据。

当导入的单个文件很大时，单线程解决模式无奈充分利用数据库的资源，导致执行工夫很长。又因为load data导入的数据在一个事务内，当binlog事务超过2G时，可能会导致无奈应用binlog在MGR集群间同步。

为解决上述两个问题，GreatSQL反对了load data并行导入。开启并行导入后，会主动切分文件成小块（可配置），而后启动多个worker线程（数量可配置）导入文件块。并行导入与engine无关，实践上反对任何存储引擎。

更多信息详见文档：GreatSQL中的并行load data个性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.3.2 优化器优化

优化了执行打算，使得benchmark tpcc测试吞吐量更高，也更加稳固。

1.4 平安

1.4.1 mysqldump备份加密

GreatSQL 8.0.32-24反对在mysqldump进行逻辑备份时产生加密备份文件，并且也反对对加密后的备份文件解密导入。

更多信息详见文档：GreatSQL中的逻辑备份加密个性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.4.2 审计日志入表

GreatSQL反对将审计日志写入数据表中，并且设置审计日志入表规定，以便达到不同的审计需要。

审计内容将包含操作账户、客户端ip、被操作的数据库对象、操作的残缺语句、操作后果。

更多信息详见文档：GreatSQL中的审计日志入表个性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.4.3 表空间国密加密

在开源MySQL原有keyring架构，通过国密算法，加强开源MySQL keyring架构的安全性。MySQL的表空间加密keyring架构蕴含2层加密，master key 和 tablespace key。

• master key用于加密tablespace key，加密后的后果存储在tablespace的header中。
• tablespace key用于加密数据

当用户想拜访加密的表时，InnoDB会先用master key对之前存储在header中的加密信息进行解密，失去tablespace key。再用tablespace key解密数据信息。tablespace key是不会被扭转的，而master key能够随时扭转。开源MySQL的master key采纳keyring_file插件，key file间接存储在磁盘上。

本性能点通过基于国密算法sm4，减少了数据库的安全性。

创立国密算法加密表

CREATE TABLE test.t1(c1 INT, c2 INT) ENGINE = InnoDB ENCRYPTION = 'Y';

更多信息详见文档：GreatSQL中的表空间加密国密反对（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

1.4.4 CLONE备份加密

GreatSQL反对在利用CLONE备份时同步进行加密操作，晋升备份文件安全性，防止备份文件被盗或透露时造成损失。

更多信息详见文档：CLONE备份加密（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/...）

2.稳定性晋升

3.其余调整

4.bug修复

• 修复InnoDB并行查问可能导致查问hang住，甚至crash的问题。

5. GreatSQL VS MySQL

此外，GreatSQL 8.0.32-24基于Percona Server for MySQL 8.0.32-24版本，它在MySQL 8.0.32根底上做了大量的改良和晋升以及泛滥新个性，详情请见：Percona Server for MySQL feature comparison（https://docs.percona.com/percona-server/8.0/feature_compariso...），这其中包含线程池、审计、数据脱敏等MySQL企业版才有的个性，以及PFS晋升、IFS晋升、性能和可扩展性晋升、用户统计加强、processlist加强、slow log加强等大量改良和晋升，这里不一一反复列出。

6. GreatSQL Release Notes

• Changes in GreatSQL 8.0.25-17 (2023-3-13)
• Changes in GreatSQL 8.0.25-16 (2022-5-16)
• Changes in GreatSQL 8.0.25-15 (2022-8-26)
• Changes in GreatSQL 5.7.36-39 (2022-4-7)

Enjoy GreatSQL :)

## 对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

相干链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

社区博客有奖征稿详情：https://greatsql.cn/thread-100-1-1.html

技术交换群：

微信：扫码增加GreatSQL社区助手微信好友，发送验证信息加群。