GreatSQL 8.0.32-24 今日发布

• 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.32-24

• 项目文档：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/greatsql-803224/sql-compat.md）**

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/greatsql-803224/mgr-vip.md）**

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/greatsql-803224/parallel_load_data.md）**

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/greatsql-803224/mysqldump-encrypt.md）**

1.4.2 审计日志入表

GreatSQL 支持将审计日志写入数据表中，并且设置审计日志入表规则，以便达到不同的审计需求。

审计内容将包括操作账户、客户端 ip、被操作的数据库对象、操作的完整语句、操作结果。

更多信息详见文档：GreatSQL 中的审计日志入表特性**（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/audit-log-in-table.md）**

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/greatsql-803224/innodb-tablespace-encrypt.md）**

1.4.4 CLONE 备份加密

GreatSQL 支持在利用 CLONE 备份时同步进行加密操作，提升备份文件安全性，避免备份文件被盗或泄漏时造成损失。

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

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_comparison.html#percona-server-for-mysql-feature-comparison）**，这其中包括线程池、审计、数据脱敏等 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)