如何通过 Docker 持久化存储策略实现数据库容器平滑迁移指南

数据库容器迁移需完整复现运行状态：镜像+持久化数据+启动逻辑；命名卷需导出解压，绑定挂载同步目录，未持久化须紧急补救；同步镜像、配置及验证环境一致性。

要让数据库容器在迁移后数据不丢、服务不停、配置不乱，关键不是“搬容器”，而是完整复现它的运行状态：镜像 + 持久化数据 + 启动逻辑。直接用 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，确保端口映射、环境变量、挂载关系完全一致。

不复杂但容易忽略。