使用 MySQL Shell 进行 MySQL 单机到 InnoDB Cluster 的数据迁移实践

迁移背景与环境

原来都是用mysqldump，DTS或者cdc迁移，这次8.0用了下新工具感觉挺好用的，简单快捷，30G数据不到

源环境：单机 MySQL 8.0，地址为 172.23.3.28

目标环境：InnoDB Cluster 集群（3 节点），其中主节点地址为 172.23.3.4

特殊情况：集群中一台节点（172.23.3.79）配置较低，存在 "木桶效应" 导致节点频繁卡死，需要在迁移前进行处理

迁移前的准备工作

由于集群中 172.23.3.79 节点配置较低，成为整个集群的性能瓶颈，在正式迁移前需要先将其从集群中移除：

1. 登录主节点的 MySQL Shell：

mysqlsh --user=root --password='pwd' --uri localhost:3306

1. 移除低配置节点：javascript

c = dba.getCluster()
c.removeInstance('172.23.3.79:3306',{force:true})

1. 验证集群状态，确保节点已成功移除：

c.status()

数据迁移实施步骤

1. 准备源数据库

为保证数据一致性，先将源数据库设置为只读模式：

SET GLOBAL read_only = ON;

2. 使用 MySQL Shell 导出数据

通过 MySQL Shell 的 util.dumpInstance 工具从源库导出数据到主节点目录：

mysqlsh --user=migration --password='pwd' --uri 172.23.3.28:3306

在 MySQL Shell 交互模式中执行导出命令：

util.dumpInstance('/data/mysql_dump_dir', { 
    threads: 8,                 // 使用8个线程加速导出
    showProgress: true,         // 显示导出进度
    consistent: true,           // 保证数据一致性
    ocimds: false,              // 非OCI环境
    excludeTables: [            // 排除不需要迁移的表
        "d.qttq",
        "d.dept_temp",
    ]
});

3. 处理用户授权信息

为避免迁移过程中的授权错误，替换导出的用户信息文件：

cp /usr/local/src/user.sql.bak /data/mysql_dump_dir/\@.users.sql

4. 导入数据到主节点

登录目标集群的主节点，使用 util.loadDump 工具导入数据：

bash

mysqlsh --user=root --password=Scjzbd@123.com --uri 172.23.3.4:3306

在 MySQL Shell 交互模式中执行导入命令：

util.loadDump('/data/mysql_dump_dir', {
    threads: 32,                // 使用32个线程加速导入
    showProgress: true,         // 显示导入进度
    deferTableIndexes: 'all',   // 延迟创建索引以提高导入速度
    loadUsers: true,            // 导入用户信息
    resetProgress: true
});

迁移后的集群调整

数据导入完成后，需要将之前移除的节点重新加入集群：

1. 确认集群状态正常：

c = dba.getCluster()
c.status()

1. 添加节点到集群（使用 clone 方式进行数据同步）：

c.addInstance('172.23.3.79', {recoveryMethod: 'clone'})

总结

使用 MySQL Shell 的 util.dumpInstance 和 util.loadDump 工具进行数据迁移，相比传统的 mysqldump 具有以下优势：

1. 多线程操作，迁移速度更快
2. 可以排除不需要的表，提高迁移效率
3. 内置进度显示，便于监控迁移过程
4. 更好地支持 InnoDB Cluster 环境

在迁移包含性能不均衡节点的集群时，先移除低配置节点可以避免迁移过程中出现的性能瓶颈和节点卡死问题，待迁移完成后再将节点重新加入集群，