§ MySQL迁移/升级/降级到GreatSQL
本文介绍如何从MySQL迁移/升级到GreatSQL数据库。
§ 为什么要迁移/升级
GreatSQL相对于MySQL社区版有着众多优秀特性,包括且不仅限以下:
1.主要特性 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
---|---|---|
开源 | ✔️ | ✔️ |
ACID 完整性 | ✔️ | ✔️ |
MVCC 特性 | ✔️ | ✔️ |
支持行锁 | ✔️ | ✔️ |
Crash 自动修复 | ✔️ | ✔️ |
表分区(Partitioning) | ✔️ | ✔️ |
视图(Views) | ✔️ | ✔️ |
子查询(Subqueries) | ✔️ | ✔️ |
触发器(Triggers) | ✔️ | ✔️ |
存储程序(Stored Programs) | ✔️ | ✔️ |
外键(Foreign Keys) | ✔️ | ✔️ |
窗口函数(Window Functions) | ✔️ | ✔️ |
通用表表达式 CTE | ✔️ | ✔️ |
地理信息(GIS) | ✔️ | ✔️ |
基于 GTID 的复制 | ✔️ | ✔️ |
组复制(MGR) | ✔️ | ✔️ |
MyRocks 引擎 | ✔️ | ❌ |
支持龙芯架构 | ✔️ | ❌ |
2. 性能提升扩展 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
AP 引擎 | ✔️ | 仅云上HeatWave |
NUMA 亲和性优化 | ✔️ | ❌ |
非阻塞式 DDL | ✔️ | ❌ |
无主键表导入优化 | ✔️ | ❌ |
InnoDB 并行查询 | ✔️ | 仅主键扫描 |
并行 LOAD DATA | ✔️ | ❌ |
InnoDB 事务 ReadView 无锁优化 | ✔️ | ❌ |
InnoDB 事务大锁拆分优化 | ✔️ | ❌ |
InnoDB 资源组 | ✔️ | ✔️ |
自定义 InnoDB 页大小 | ✔️ | ✔️ |
Contention-Aware Transaction Scheduling | ✔️ | ✔️ |
InnoDB Mutexes 拆分优化 | ✔️ | ❌ |
MEMORY 引擎优化 | ✔️ | ❌ |
InnoDB Flushing 优化 | ✔️ | ❌ |
并行 Doublewrite Buffer | ✔️ | ✔️ |
InnoDB 快速索引创建优化 | ✔️ | ❌ |
VARCHAR/BLOB/JSON 类型存储单列压缩 | ✔️ | ❌ |
数据字典中存储单列压缩信息 | ✔️ | ❌ |
3. 面向开发者提升改进 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
X API | ✔️ | ✔️ |
JSON | ✔️ | ✔️ |
NoSQL Socket-Level接口 | ✔️ | ✔️ |
InnoDB 全文搜索改进 | ✔️ | ❌ |
更多 Hash/Digest 函数 | ✔️ | ❌ |
Oracle 兼容-数据类型 | ✔️ | ❌ |
Oracle 兼容-函数 | ✔️ | ❌ |
Oracle 兼容-SQL语法 | ✔️ | ❌ |
Oracle 兼容-存储程序 | ✔️ | ❌ |
4. 基础特性提升改进 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
MGR 提升-地理标签 | ✔️ | ❌ |
MGR 提升-仲裁节点 | ✔️ | ❌ |
MGR 提升-读写节点绑定VIP | ✔️ | ❌ |
MGR 提升-快速单主模式 | ✔️ | ❌ |
MGR 提升-智能选主机制 | ✔️ | ❌ |
MGR 提升-全新流控算法 | ✔️ | ❌ |
MGR 提升-网络分区异常处理 | ✔️ | ❌ |
MGR 提升-节点异常退出处理 | ✔️ | ❌ |
MGR 提升-节点磁盘满处理 | ✔️ | ❌ |
MGR 提升-自动选择 donor 节点 | ✔️ | ❌ |
Clone 增量备份 | ✔️ | ❌ |
Clone 备份压缩 | ✔️ | ❌ |
Binlog 读取限速 | ✔️ | ❌ |
information_schema 表数量 | 95 | 65 |
全局性能和状态指标 | 853 | 434 |
优化器直方图(Histograms) | ✔️ | ✔️ |
Per-Table 性能指标 | ✔️ | ❌ |
Per-Index 性能指标 | ✔️ | ❌ |
Per-User 性能指标 | ✔️ | ❌ |
Per-Client 性能指标 | ✔️ | ❌ |
Per-Thread 性能指标 | ✔️ | ❌ |
全局查询相应耗时统计 | ✔️ | ❌ |
SHOW INNODB ENGINE STATUS 增强 | ✔️ | ❌ |
回滚段信息增强 | ✔️ | ❌ |
临时表信息增强 | ✔️ | ❌ |
用户统计信息增强 | ✔️ | ❌ |
Slow log 信息增强 | ✔️ | ❌ |
5.安全性提升 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
国密支持 | ✔️ | ❌ |
备份加密 | ✔️ | ❌ |
审计 | ✔️ | 仅企业版 |
数据脱敏 | ✔️ | ❌ |
最后登录记录 | ✔️ | ❌ |
SQL Roles | ✔️ | ✔️ |
SHA-2 密码Hashing | ✔️ | ✔️ |
密码轮换策略 | ✔️ | ✔️ |
PAM 认证插件 | ✔️ | 仅企业版 |
Keyring 存储在文件中 | ✔️ | ✔️ |
Keyring 存储在Hashicorp Vault中 | ✔️ | 仅企业版 |
InnoDB 数据加密 | ✔️ | ✔️ |
InnoDB 日志加密 | ✔️ | ✔️ |
InnoDB 各种表空间文件加密 | ✔️ | ✔️ |
二进制日志加密 | ✔️ | ❌ |
临时文件加密 | ✔️ | ❌ |
强制加密 | ✔️ | ❌ |
6. 运维便利性提升 | GreatSQL 8.0.32-26 | MySQL 8.0.32 |
DDL 原子性 | ✔️ | ✔️ |
数据字典存储 InnoDB 表 | ✔️ | ✔️ |
快速 DDL | ✔️ | ✔️ |
SET PERSIST | ✔️ | ✔️ |
不可见索引 | ✔️ | ✔️ |
线程池(Threadpool) | ✔️ | 仅企业版 |
备份锁 | ✔️ | ❌ |
SHOW GRANTS 扩展 | ✔️ | ❌ |
表损坏动作扩展 | ✔️ | ❌ |
杀掉不活跃事务 | ✔️ | ❌ |
START TRANSACTION WITH CONSISTENT SNAPSHOT 扩展 | ✔️ | ❌ |
§ 迁移/升级前准备
首先下载GreatSQL 8.0版本安装包,推荐选择最新的GreatSQL 8.0.32-26版本 (opens new window),至于选择RPM还是二进制包看具体情况及个人喜好。
推荐使用 GreatSQL Shell 进行升级前的检查工作,并提前修复整改可能存在的问题,详情参考:升级检查。
本文选用二进制包方式安装。
正式迁移/升级之前,务必做好数据备份,可以采用以下几种方式:
- 停机维护,复制当前的数据库目录,做一个全量物理备份,这种方式恢复起来最快。
- 利用mysqldump/xtrabackup等备份工具,执行一个全量备份。
- 利用主从复制或MGR,在其中一个节点执行备份,或者令某个节点临时下线/退出,作为备用节点。
接下来,要区分本次迁移/升级属于以下哪种情况:
- 从MySQL 5.7直接一次性迁移+升级到GreatSQL 8.0.32。
- 从MySQL 8.0.32及以下版本迁移/升级到GreatSQL 8.0.32。
- 从MySQL 5.6及更低版本迁移+升级到GreatSQL 8.0.32,则应该先逐次升级大版本,例如5.5=>5.6,5.6=>5.7最新版本,而后再一次性升级到GreatSQL 8.0.32-26。
如果是前两种,直接参考文档:GreatSQL 5.7升级到8.0 的方法进行迁移/升级即可,过程是完全一样的。
本文重点说说第三种场景。
§ 迁移过程
GreatSQL数据库是不支持直接原地(in-place)降级的,因此需要采用 逻辑备份+导入 的方式完成迁移。
如果是直接在MySQL 8.0.33及以上版本的datadir下,指定GreatSQL 8.0.32-26版本的mysqld二进制文件启动,则可能会报告类似下面的错误:
[ERROR] [MY-012530] [InnoDB] Unknown redo log format (5). Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/ upgrading-downgrading.html.
[ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Generic error.
[ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
[ERROR] [MY-010119] [Server] Aborting
2
3
4
5
即便用xtrabackup工具物理备份的文件恢复后,也是无法启动的,也会报告类似上面的错误信息。
因此,只有一种方法,那就是 逻辑备份+导入。
首先,用 mysqldump
备份全部数据:
mysqldump -S/data/MySQL/mysql.sock -A --triggers --routines --events > /backup/MySQL/fullbackup-`date +'%Y%m%d'`.sql
将备份文件copy到GreatSQL版本环境中,并执行导入即可,导入过程中可能会报错,加上 -f
选项并忽略这些错误就好(高版本中有些表在低版本中不存在,略过)。
$ mysql -S/data/GreatSQL/mysql.sock -f < /backup/MySQL/fullbackup-`date +'%Y%m%d'`.sql
#可能会报告类似下面的错误信息,忽略即可
...
ERROR 3723 (HY000) at line 543: The table 'replication_group_configuration_version' may not be created in the reserved tablespace 'mysql'.
ERROR 1146 (42S02) at line 554: Table 'mysql.replication_group_configuration_version' doesn't exist
ERROR 1146 (42S02) at line 555: Table 'mysql.replication_group_configuration_version' doesn't exist
ERROR 1146 (42S02) at line 556: Table 'mysql.replication_group_configuration_version' doesn't exist
ERROR 1146 (42S02) at line 557: Table 'mysql.replication_group_configuration_version' doesn't exist
ERROR 3723 (HY000) at line 567: The table 'replication_group_member_actions' may not be created in the reserved tablespace 'mysql'.
ERROR 1146 (42S02) at line 583: Table 'mysql.replication_group_member_actions' doesn't exist
ERROR 1146 (42S02) at line 584: Table 'mysql.replication_group_member_actions' doesn't exist
ERROR 1146 (42S02) at line 585: Table 'mysql.replication_group_member_actions' doesn't exist
ERROR 1146 (42S02) at line 586: Table 'mysql.replication_group_member_actions' doesn't exist
...
2
3
4
5
6
7
8
9
10
11
12
13
14
15
如果数据量较大的话,逻辑备份+导入过程耗时较久,要有心理准备。
§ 降级到 GreatSQL 8.0.32-26
如果是要从 MySQL 8.0.32 之后的版本降级到 GreatSQL 8.0.32-26 版本,则需要采取逻辑备份 + 逻辑导入方式完成降级操作(不支持直接在原来的 datadir 基础上原地启动 GreatSQL 8.0.32-26 完成降级替换),并且在逻辑备份导入完成后的首次重启时,务必设置 upgrade = FORCE
强制升级所有数据表,包括系统表。
降级过程操作大致如下所示:
- 在高版本中逻辑备份全量数据
mysqldump -S/data/MySQL/mysql.sock -A --triggers --routines --events --single-transaction > /data/backup/fulldump.sql
- 在GreatSQL 8.0.32-26版本环境中导入逻辑备份文件,完成逻辑恢复
mysql -S/data/GreatSQL/mysql.sock -f < /data/backup/fulldump.sql
- 修改my.cnf,确保 upgrade = FORCE 设置
[mysqld]
upgrade = FORCE
2
- 重启GreatSQL,降级完成
systemctl restart greatsql
重启过程中,可以看到日志有类似下面的强制升级过程
[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.
2
3
4
5
6
7
如果不设置 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
2
§ 注意事项
在MySQL 8.0.26中引入MGR组视图UUID特性(group_replication_view_change_uuid
(opens new window))。因此,如果当前有个MGR集群的版本是8.0.25及以下,则无法实现平滑升级迁移到8.0.26版本。需要申请一次停机维护时间,对MGR集群中的各个节点实施in-place升级,完成从8.0.25到8.0.26及更高版本的升级。
详情请参考:将MGR集群从GreatSQL-8.0.25平滑升级到GreatSQL-8.0.32 (opens new window)。
参考文档
- Percona Server for MySQL In-Place Upgrading Guide: From 5.7 to 8.0 (opens new window)
- Changes in MySQL 8.0 (opens new window)
- Before You Begin (opens new window)
- What the MySQL Upgrade Process Upgrades (opens new window)
- MySQL 5.7 MGR平滑升级到GreatSQL 5.7 (opens new window)
扫码关注微信公众号