写点什么

GreatSQL 8.0.32-26 今日发布

作者:GreatSQL
  • 2024-08-05
    福建
  • 本文字数:6477 字

    阅读完需:约 21 分钟

GreatSQL 8.0.32-26 今日发布

GreatSQL 8.0.32-26 今日发布

版本信息

特性增强

GreatSQL 8.0.32-26 版本在 高可用高性能高兼容高安全 等多方面都有增强新特性,包括 Clone 增量备份、压缩备份,MGR 新加入成员节点时自动选择最新数据节点为 donor 节点,NUMA 亲和性优化,非阻塞式 DDL,无主键表导入优化,更多 Oracle 兼容用法,最后登录信息,基于规则的数据脱敏功能等多个新特性。

高可用

  • 当有新成员节点加入 MGR 时,如果选择 Clone 方式复制数据,支持自动选择从最新事务数据的成员节点复制数据,可有效提升 Clone 速度,提高 MGR 的服务可靠性。当新加入节点触发 Clone 方式复制数据时,也支持该特性。

    参数 group_replication_donor_threshold 用于定义选择 donor 节点时判断事务延迟阈值,取值范围 [1, MAX],默认值为 MAX。MAX 值取决于 CPU 类型,在 32-bit 系统中是 2147483647(2^31-1),而在 64-bit 系统中是 9223372036854775807(2^63-1)。

    当新成员节点加入 MGR 时,新成员节点只会选择那些延迟小于 group_replication_donor_threshold 的节点作为 donor 节点。

    假设 group_replication_donor_threshold = 100,那么:

  1. 现在 MGR 中有两个节点 A、B,它们的 GTID 分别是 [1-300]、[1-280],新节点 C 加入,由于 A & B 节点的 GTID 差值小于预设阈值,则随机选择 A 或 B 其中一个节点作为 donor 节点。

  2. 现在 MGR 中有两个节点 A、B,它们的 GTID 分别是 [1-400]、[1-280],新节点 C 加入,由于 A & B 节点的 GTID 差值大于预设阈值,则只会选择 A 作为 donor 节点。

  3. 现在 MGR 中有三个节点 A、B、C,它们的 GTID 分别是 [1-400]、[1-350]、[1-280],新节点 D 加入,由于 C 节点的 GTID 差值大于预设阈值,A & B 节点 GTID 延迟小于预设阈值,则会随机选择 A 或 B 其中一个作为 donor 节点。

  • 在主从复制中,由从节点向主节点发起 Binlog 读取请求,如果读取太快或并发太多线程就会加大主节点的压力。新增参数 rpl_read_binlog_speed_limit 用于控制从节点上向主节点发起 Binlog 读取请求的限速,这对于控制主从复制中的网络带宽使用率、降低主节点压力、或在数据恢复过程中降低消耗资源非常有用。该参数可在从节点端设置生效。

    Binlog 读取限速 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-binlog-speed-limit.html

  • 优化了在 快速单主模式 下 relay log 应用逻辑,提升 MGR 整体性能;并优化了当 relay log 存在堆积时的 applier 线程的内存消耗异常情况。

    快速单主模式 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-mgr-fast-mode.html

  • 优化了 asynchronous connection failover 中的故障检测效率,特别是发生网络故障时,备用集群能更快完成主从复制通道调整,降低主从复制链路断开的时间,提高整体可用性。以设置 MASTER_RETRY_COUNT = 2 为例(slave_net_timeoutMASTER_CONNECT_RETRY 默认值均为 60),在主从复制通道间发生网络故障时导致的复制中断持续约 3 分钟,优化后故障影响时长缩短到 10 - 20 秒以内。可以利用 asynchronous connection failover 实现两个 MGR 集群间的主从复制,实现跨机房间的高可用切换方案。

    asynchronous connection failover ➥ https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-connection-failover.html

  • 地理标签 功能中包含两个参数 group_replication_zone_id(默认值为 0)和 group_replication_zone_id_sync_mode(默认值为 ON)。在旧版本中,要求各个节点的 group_replication_zone_id_sync_mode 保持一致,否则无法加入 MGR。新版本中,允许仲裁节点设置不同的 group_replication_zone_id_sync_mode。例如,节点 A1、A2 设置 group_replication_zone_id = 0 & zone_id_sync_mode = ON;节点 B1、B2 设置 group_replication_zone_id = 1,它们也必须设置 zone_id_sync_mode = ON;仲裁投票节点 C 设置 group_replication_zone_id = 2,但可以设置 group_replication_zone_id_sync_mode = OFF

    地理标签 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-mgr-zoneid.html

  • 当启用 greatdb_ha Plugin 时,新增支持 IPv6。

更多信息详见文档:高可用 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha.html

高性能

更多信息详见文档:高性能 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-1-highperf.html

高兼容

更多信息详见文档:高兼容 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-3-easyuse.html

高安全

更多信息详见文档:高安全 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-4-security.html

其他

缺陷修复

  • 修复了在部分 ARM 架构环境中无法使用并行复制的问题,详见:MySQL Bug 110752 ➥ https://bugs.mysql.com/bug.php?id=110752

  • 修复了最后登录信息和审计日志入表时未处理 Binlog 可能导致主从异常的问题。在新版本中,最后登录信息和审计日志都不会记录 Binlog,避免因为主从复制(也包括 MGR)中各实例都开启该特性记录 Binlog 而造成主从复制失败(或 MGR 报错)。

  • 修复了数个因为 SQL 注入可能导致数据库实例发生 coredump 的问题,大幅提升 GreatSQL 对 SQL 注入风险的抵御能力。

  • 修复了 Oracle 模式下 NULL 值唯一约束问题。在原来的 Oracle 模式下,插入 NULL 值会触发唯一约束冲突;而在 Oracle 数据库中,是允许向唯一约束列中重复写入 NULL 值的。在新版本中修复了这个问题。

-- 在老版本中greatsql> SET sql_mode = ORACLE;greatsql> CREATE TABLE t1 (c1 INT UNIQUE);greatsql> SHOW CREATE TABLE t1\G*************************** 1. row ***************************       Table: t1Create Table: CREATE TABLE "t1" (  "my_row_id" bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,  "c1" int DEFAULT NULL,  PRIMARY KEY ("my_row_id"),  UNIQUE KEY "c1" ("c1") /* nulls are equal in unique index as oracle does */) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
greatsql> INSERT INTO t1 SELECT NULL;Query OK, 1 row affected (0.01 sec)Records: 1 Duplicates: 0 Warnings: 0
greatsql> INSERT INTO t1 SELECT NULL;ERROR 1062 (23000): Duplicate entry 'NULL' for key 't1.c1'
复制代码

在新版本中修复了这个唯一性约束问题:

-- 在新版本中greatsql> SET sql_mode = ORACLE;greatsql> CREATE TABLE t1 (c1 INT UNIQUE);greatsql> SHOW CREATE TABLE t1\G*************************** 1. row ***************************       Table: t1Create Table: CREATE TABLE "t1" (  "my_row_id" bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,  "c1" int DEFAULT NULL,  PRIMARY KEY ("my_row_id"),  UNIQUE KEY "c1" ("c1") /* nulls are equal in unique index as oracle does */) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
greatsql> INSERT INTO t1 SELECT NULL;Query OK, 1 row affected (0.01 sec)Records: 1 Duplicates: 0 Warnings: 0
-- 不再报告唯一性约束冲突greatsql> INSERT INTO t1 SELECT NULL;Query OK, 1 row affected (0.01 sec)Records: 1 Duplicates: 0 Warnings: 0
复制代码

注意事项

无。

升级/降级到 GreatSQL 8.0.32-26

升级到 GreatSQL 8.0.32-26

以下是升级到 GreatSQL 8.0.32-26 的几种不同场景说明。

  • 如果旧版本是 GreatSQL 8.0.32-25,并且没有使用 Rapid 引擎,则可以直接在原来的 datadir 基础上,修改 basedir 后,原地(in-place)启动 GreatSQL 8.0.32-26 后会完成自动升级。

  • 如果旧版本是 GreatSQL 8.0.32-25,并且已启用 Rapid 引擎,这种情况下暂时先不要升级,可以等到后续发布带新版本 Rapid 引擎的 GreatSQL 8.0.32-26 版本后再升级。

  • 如果旧版本是 GreatSQL 8.0.32-24、8.0.25-、5.7.36-39 等系列版本,则可以直接在原来的 *datadir 基础上,修改 basedir 后,原地(in-place)启动 GreatSQL 8.0.32-26 后会完成自动升级。

  • 如果是 MySQL 8.0.(<= 8.0.32 版本)、Percona Server 8.0.*(<= 8.0.32 版本)等系列版本,则可以直接在原来的 *datadir 基础上,修改 basedir 后,原地(in-place)启动 GreatSQL 8.0.32-26 后会完成自动升级。

  • 如果是 MySQL 8.0.(> 8.0.32 版本)、Percona Server 8.0.(> 8.0.32 版本)等系列版本,则需要利用逻辑备份方式导出数据,再导入的方式完成升级,不支持原地(in-place)升级到 GreatSQL 8.0.32-26。

  • 如果是 MySQL 5.7.(>= 5.7.23 版本)、Percona Server 5.7.*(<= 5.7.23 版本)等系列版本,则可以直接在原来的 *datadir 基础上,修改 basedir 后,原地(in-place)启动 GreatSQL 8.0.32-26 后会完成自动升级。

在以上几个原地升级场景中,务必保证 GreatSQL 中参数 upgrade 不能设置为 NONE*,可以设置为默认的 *AUTOFORCE。例如:

[mysqld]upgrade = AUTO
复制代码

更多迁移升级方案请参考:迁移升级

降级到 GreatSQL 8.0.32-26

如果是要从 MySQL/Percona 8.0.32 之后的版本降级到 GreatSQL 8.0.32-26 版本,则需要采取逻辑备份 + 逻辑导入方式完成降级操作,并且在逻辑备份导入完成后的首次重启时,务必设置 upgrade = FORCE 强制升级所有数据表,包括系统表。

降级过程操作大致如下所示:

  1. 在高版本中逻辑备份全量数据

    $ mysqldump -S/data/MySQL/mysql.sock -A --triggers --routines --events --single-transaction > /data/backup/fulldump.sql

  2. 在 GreatSQL 8.0.32-26 版本环境中导入逻辑备份文件,完成逻辑恢复

$ mysql -S/data/GreatSQL/mysql.sock -f < /data/backup/fulldump.sql
复制代码
  1. 修改 my.cnf,确保 upgrade = FORCE 设置

    $ vim /etc/my.cnf ... [mysqld] ... upgrade = FORCE ...

  2. 重启 GreatSQL,降级完成

$ systemctl restart greatsql
复制代码

重启过程中,可以看到日志有类似下面的强制升级过程

$ tail -f /data/GreatSQL/error.log...[Note] [MY-013387] [Server] Upgrading system table data.[Note] [MY-013385] [Server] Upgrading the sys schema.[Note] [MY-013400] [Server] Upgrade of help tables started.[Note] [MY-013400] [Server] Upgrade of help tables completed.[Note] [MY-013394] [Server] Checking 'mysql' schema.[Note] [MY-013394] [Server] Checking 'sys' schema.[System] [MY-013381] [Server] Server upgrade from '80032' to '80032' completed....
复制代码

如果不设置 upgrade = FORCE 强制升级所有表,有可能发生系统表 mysql.procs_priv 损坏错误,在创建用户时可能会报告类似下面的错误:

greatsql> create user tpch identified by 'tpch';ERROR 1728 (HY000): Cannot load from mysql.procs_priv. The table is probably corrupted
复制代码

GreatSQL VS MySQL

GreatSQL 8.0.32-26 基于 Percona Server for MySQL 8.0.32 版本,它在 MySQL 8.0.32 基础上做了大量的改进和提升以及众多新特性,详情请见:Percona Server for MySQL feature comparison ➥ https://docs.percona.com/percona-server/8.0/feature-comparison.html,这其中包括线程池、审计、数据脱敏等 MySQL 企业版才有的特性,以及 performance_schema 提升、information_schema 提升、性能和可扩展性提升、用户统计增强、PROCESSLIST 增强、Slow Log 增强等大量改进和提升,这里不一一重复列出。

GreatSQL Release Notes

GreatSQL 8.0

GreatSQL 5.7

发布于: 刚刚阅读数: 4
用户头像

GreatSQL

关注

GreatSQL社区 2023-01-31 加入

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。 社区:https://greatsql.cn/ Gitee: https://gitee.com/GreatSQL/GreatSQL

评论

发布
暂无评论
GreatSQL 8.0.32-26 今日发布_新版本_GreatSQL_InfoQ写作社区