MySQL容器迁移应采用数据导出/导入+配置重建+服务切换方案；用mysqldump导出全库（推荐--single-transaction），复制backup.sql至目标容器后导入。
MySQL 容器迁移的核心是数据安全、服务连续性和配置一致性。直接拷贝容器或镜像不可靠，应聚焦于数据导出/导入 + 配置重建 + 服务切换。
备份与还原：用 mysqldump 迁移数据
这是最通用、兼容性最好的方式，适用于跨版本、跨主机、甚至跨平台迁移。
- 在源容器中导出全库（含创建语句和数据）：
docker exec mysql-source mysqldump -u root -p'yourpass' --all-databases --single-transaction > backup.sql
（建议加--single-transaction减少锁表，适合 InnoDB） - 将备份文件复制到目标环境：
docker cp backup.sql mysql-target:/tmp/ - 在目标容器中导入：
docker exec -i mysql-target mysql -u root -p'yourpass'
卷（Volume）迁移：保留原始数据目录
适合同版本、同架构、且希望跳过逻辑导入的场景，速度快、不依赖 SQL 解析。
- 确认源容器使用命名卷（如
mysql-data）或绑定挂载路径；
查看命令：docker volume inspect mysql-data 或检查docker inspect中的Mounts - 停止源容器：docker stop mysql-source
- 将卷内容打包（若为命名卷，需临时挂载到 busybox 容器中）：
docker run --rm -v mysql-data:/volume -v $(pwd):/backup alpine tar czf /backup/mysql-data.tar.gz -C /volume . - 在目标主机解压到对应路径或新建同名卷，启动新容器时复用该卷。
配置与启动参数同步
容器迁移后功能异常，80% 源于配置不一致。关键项必须核对：
-
字符集与排序规则：检查
my.cnf中character-set-server=utf8mb4和collation-server=utf8mb4_0900_ai_ci（MySQL 8.0+） -
binlog 与 GTID：若需后续主从或恢复点，确保
log-bin、server-id、gtid_mode=ON等已启用并唯一 - 挂载路径与权限：数据目录、配置文件、SSL 证书路径需在新容器中正确映射，且 MySQL 用户（uid/gid）有读写权限
- 推荐把
my.cnf单独挂载为 config 文件，便于版本管理和快速调整
平滑切换与验证
避免停机时间过长或应用报错，迁移后务必验证再切流。
- 启动新容器后，先连接测试：docker exec -it mysql-new mysql -u root -p -e "SHOW DATABASES;"
- 比对关键表行数、校验和（如
CHECKSUM TABLE t1;），确认数据完整性 - 检查慢查询日志、错误日志是否正常生成；观察连接数、QPS 是否符合预期
- 更新应用配置指向新容器 IP/端口，或通过 DNS/Service Mesh 切换流量
