数据库容器迁移需完整复现运行状态：镜像+持久化数据+启动逻辑；命名卷需导出解压，绑定挂载同步目录，未持久化须紧急补救；同步镜像、配置及验证环境一致性。
要让数据库容器在迁移后数据不丢、服务不停、配置不乱，关键不是“搬容器”，而是完整复现它的运行状态：镜像 + 持久化数据 + 启动逻辑。直接用 docker export 或只传镜像，都会导致数据丢失或启动失败。
明确持久化方式，决定迁移路径
先确认你的数据库容器用的是哪种存储方式，这直接影响操作步骤：
-
命名卷（推荐）：如
docker volume create dbdata并在docker run或docker-compose.yml中通过volumes: - dbdata:/var/lib/mysql挂载。这类卷由 Docker 管理，路径抽象，迁移时需单独导出内容，不能靠复制宿主机目录。 -
绑定挂载（Bind Mount）：如
-v /opt/mysql/data:/var/lib/mysql。数据直落宿主机目录，迁移时只需同步该目录（rsync或scp即可），但要注意目标机路径权限、SELinux 上下文（如 CentOS）、以及 MySQL 对文件属主的严格要求（通常为mysql:mysql）。 -
未持久化（危险！）：容器内数据仅存于可写层。一旦容器删除，数据彻底消失。迁移前必须立即补救：停容器 →
docker commit→docker save，再配合docker cp把关键目录（如/var/lib/mysql）拷出来，否则无法恢复。
命名卷迁移：导出、传输、重建
这是最规范也最常被忽略的环节。命名卷本身不随镜像走，必须手动处理：
- 在源服务器上，用临时容器打包卷内容：
docker run --rm -v dbdata:/data -v $(pwd):/backup alpine tar czf /backup/dbdata.tar.gz -C /data . - 把生成的
dbdata.tar.gz传到目标机：scp dbdata.tar.gz user@target:/tmp/ - 在目标机创建同名空卷：
docker volume create dbdata - 解压进新卷：
docker run --rm -v dbdata:/data -v $(pwd):/backup alpine sh -c "cd /data && tar xzf /backup/dbdata.tar.gz"
注意：MySQL 停机状态下执行更安全；若需热迁移，建议先 mysqldump 或使用 XtraBackup，再还原到新卷。
镜像与启动配置同步
光有数据还不够，镜像版本和启动参数必须一致：
- 如果数据库容器做过配置修改（如调过
my.cnf、装过插件），先docker stop mysql-container，再docker commit mysql-container my-mysql:v1.2，最后docker save -o my-mysql-v1.2.tar my-mysql:v1.2传过去并docker load -i加载。 - 若用
docker-compose.yml部署，务必一并打包：
包括docker-compose.yml、.env、自定义配置目录（如./conf/my.cnf）、初始化脚本目录（如./init/）。 - 检查目标机 Docker 版本是否匹配（主版本号一致，如都是 24.x），
docker info | grep "Storage Driver"确认存储驱动（如overlay2）相同，避免加载异常。
验证与收尾要点
迁移完成后别急着切流，做三件事：
- 启动容器后，进容器执行
mysql -uroot -p -e "SHOW DATABASES;"，确认库表存在且可查； - 检查日志：
docker logs mysql-container | tail -20，看是否有ready for connections或报错（如权限、InnoDB 文件损坏）； - 比对源容器的
docker inspect输出，重点核对NetworkSettings.Ports、HostConfig.Binds、Env，确保端口映射、环境变量、挂载关系完全一致。
不复杂但容易忽略。
