GreatSQL 8.0.32-24 今日发布

GreatSQL8.0.32-24版本引入了多项重大特性,包括增强SQL兼容性,如数据类型扩展和Oracle兼容函数;MGR中新增动态VIP支持,优化了孟子算法和Xcomcache管理;并行loaddata提高导入性能;提供mysqldump备份加密和表空间国密加密功能,增强了审计日志的安全性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  • 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

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

image-20230605090721995

0.项目信息

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进行恢复。

System Variable Namegroup_replication_applier_batch_size_threshold
Variable ScopeGlobal
Dynamic VariableYES
Permitted Values[10 ~ 100000000]
Default100000
Description当applier queue超过 group_replication_applier_batch_size_threshold 设定的阈值时,就会触发批量落盘模式,每100个event批量落盘,提高落盘效率。
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静态化初始大小:

System Variable Namegroup_replication_xcom_cache_mode
Variable ScopeGlobal
Dynamic VariableYES
Permitted Values[0 ~ 4]
Default2
Description设置Xcom cache静态化初始大小,对应关系如下: 0:约能缓存50万个Xcom条目,相应内存消耗约200MB; 1:约能缓存100万个Xcom条目,相应内存消耗约500MB; 2:约能缓存200万个Xcom条目,相应内存消耗约1GB; 3:约能缓存400万个Xcom条目,相应内存消耗约2GB; 4:约能缓存800万个Xcom条目,相应内存消耗约4GB;
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-24MySQL 8.0.32
开源
ACID完整性
MVCC特性
支持行锁
Crash自动修复
表分区(Partitioning)
视图(Views)
子查询(Subqueries)
触发器(Triggers)
存储过程(Stored Procedures)
外键(Foreign Keys)
窗口函数(Window Functions)
通用表表达式CTE
地理信息(GIS)
基于GTID的复制
组复制(MGR)
MyRocks引擎
SQL兼容扩展1.数据类型扩展 2.SQL语法扩展 共超过20个扩展新特性
MGR提升1.地理标签 2.仲裁节点 3.读写节点绑定VIP 4.快速单主模式 5.智能选主机制 6.全新流控算法
性能提升1.InnoDB并行查询 2.并行load data
安全提升1.国密支持 2.备份加密 3.审计日志入库

此外,GreatSQL 8.0.32-24基于Percona Server for MySQL 8.0.32-24版本,它在MySQL 8.0.32基础上做了大量的改进和提升以及众多新特性,详情请见:Percona Server for MySQL feature comparisonhttps://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


Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

image

社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html

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

社区2022年度勋章获奖名单: https://greatsql.cn/thread-184-1-1.html

(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)

技术交流:

image-20221030163217640

<think>好的,我现在需要解决用户关于如何安装或配置libreadline.so.7以适配greatsql-client-8.0.32-25.1.el8.x86_64的依赖问题。首先,我得回顾用户提供的引用内容,特别是引用[4],那里提到系统缺少libreadline.so.8导致安装问题,用户通过卸载并安装正确版本解决。但当前用户需要的是libreadline.so.7,可能与之前的冲突不同。 接下来,用户的环境是el8(RHEL/CentOS 8),而GreatSQL客户端需要libreadline.so.7。通常,库文件的版本兼容性很重要。可能的情况是系统中已安装的readline库版本过高(如libreadline.so.8)或者没有安装对应的版本。需要确认系统是否已经存在libreadline.so.7,或者是否需要降级安装。 根据引用[2],用户检查了/usr/lib64/libreadline.so.7是否存在,可能已经存在但符号链接不正确,或者版本不匹配。可能需要安装兼容的readline包,或者创建符号链接。另外,引用[4]中提到通过yum remove readline解决冲突,可能需要类似的方法来处理libreadline.so.7的问题。 可能的步骤包括: 1. 检查现有readline版本,确认是否有libreadline.so.7。 2. 如果没有,寻找适用于el8的readline包,例如通过yum仓库安装旧版本。 3. 处理依赖冲突,可能需要使用--setopt=protected_packages=readline来防止自动升级或降级其他依赖包。 4. 创建符号链接,确保库的正确指向。 5. 使用LD_LIBRARY_PATH或ldconfig更新库缓存。 需要注意,强制降级可能会影响其他依赖高版本readline的软件,因此需谨慎。此外,用户可能需要启用包含旧版本库的仓库,如EPEL或特定GreatSQL提供的仓库。如果系统中无法直接安装,可能需要手动编译或下载rpm包进行安装。最后,安装完成后,运行ldconfig更新动态链接库缓存,确保GreatSQL客户端能找到所需的库。</think>### 分步解决方案 #### 1. 确认当前系统readline库状态 ```bash # 检查已安装的readline包 rpm -qa | grep readline # 查看libreadline.so.7是否存在 ls -l /usr/lib64/libreadline.so.7* ``` #### 2. 安装兼容版本(根据系统类型选择) *适用于RHEL/CentOS 8:* ```bash # 从EPEL仓库安装兼容包(需先启用EPEL) yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm yum install --disablerepo=* --enablerepo=epel readline-7.0-10.el8.x86_64 ``` *如果存在版本冲突:* ```bash # 强制降级并保留依赖关系(谨慎操作) yum downgrade readline-7.0-10.el8 --setopt=protected_packages=readline ``` #### 3. 创建符号链接(如库文件未自动链接) ```bash ln -sf /usr/lib64/libreadline.so.7.0 /usr/lib64/libreadline.so.7 ``` #### 4. 更新动态链接库缓存 ```bash ldconfig -v | grep libreadline ``` #### 5. 验证GreatSQL客户端安装 ```bash # 重新尝试安装客户端 yum install greatsql-client-8.0.32-25.1.el8.x86_64 # 验证依赖解析 ldd $(which mysql) | grep libreadline ``` ### 关键配置说明 - **版本匹配原则**:GreatSQL客户端需要$libreadline.so.7$对应readline 7.x版本,与系统自带8.x版本存在符号不兼容[^4] - **安全降级**:使用$--setopt=protected_packages$参数可避免影响其他依赖高版本readline的应用程序 - **符号链接验证**:需确保$ls -l /usr/lib64/libreadline.so.7$显示有效链接,如: ``` lrwxrwxrwx. 1 root root 20 Mar 1 10:00 /usr/lib64/libreadline.so.7 -> libreadline.so.7.0 ``` ### 引用验证方法 ```bash # 检查客户端依赖解析(输出应包含libreadline.so.7) objdump -p /usr/bin/mysql | grep NEEDED ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值