关于数据库: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 社区助手 微信好友，发送验证信息 加群。