Docker 容器迁移 MySQL 实战：数据卷、备份与跨版本升级指南

先交代一下背景：我手头有套内部系统的业务库，一直跑在 Docker 容器里，最近宿主机要退役，必须把 mysql 容器和数据一起迁到新机器。一开始我下意识觉得，docker 迁移 mysql 容器不就是把镜像导出、到新机器导入再跑起来？等真上手才发现，容器迁移里最大的坑从来不是“容器”本身，而是数据、权限、字符集、启动方式这些藏在后面的细节。这篇文章就把我当时完整走的流程、做的判断和踩过的教训写出来，希望能帮准备做这件事的人少走几个来回。

我不打算讲一堆高深理论，核心就是三件事：搞清楚数据到底放在哪，选对迁移方式，容器启动配置跟着走。无论你是运维还是开发，只要接手过“当年别人随手跑起来、之后再也没人动过”的 mysql 容器，这篇应该都会对你有用。

1. 先想明白：你要迁的是数据，不是容器

很多人在迁移 docker 容器时，第一反应是docker export、docker commit或者把整个容器镜像打包带走。对无状态服务这招偶尔能行，但对 MySQL 这种有状态服务，方向一开始就偏了。

1.1 容器本身根本不值得“迁移”

Docker 容器的设计初衷就是“用完即弃”：镜像只负责提供程序运行环境，容器是一个可读写层，每次docker run都是干净的副本。你完全可以在新机器上拉同一个 MySQL 镜像再跑一个新容器，没必要把旧容器一层层原封不动搬过去。

真正需要跟着搬的是两类东西：一类是数据，也就是 MySQL 的库表文件；另一类是运行参数，比如端口映射、环境变量、自定义配置、自动重启策略。换句话说，迁移的本质是“把数据和配置搬运到新容器”，而不是“把容器搬过去”。

1.2 三种迁移诉求，对应完全不同的做法

我开始动手前先问了自己一个问题：这次迁移到底属于哪种场景？不同场景方法完全不同。

我这次属于典型第三种：新机器没有旧镜像，而且想顺手把 MySQL 从 5.7 升到 8.0，所以最终走了逻辑备份为主、物理卷验证为辅的混合路线。如果只是同版本平迁，物理拷贝反而更快。

1.3 迁移前必做的“摸底”动作

在停任何服务之前，我先花了十分钟做了三件事：查当前容器挂载、查 MySQL 版本、查业务账号依赖。命令行大概是这样的：

docker inspect mysql-server --format '{{.Config.Image}}' docker inspect mysql-server --format '{{json .Mounts}}' docker exec mysql-server mysql -uroot -p -e "select version();"

这一套做完，我心里就有数了：旧容器用的哪个镜像、数据卷挂载路径是什么、MySQL 具体版本号是多少。这里面任何一项没确认就盲目开搞，后面都很容易翻车。

2. 先认清数据卷的三张面孔：容器层、命名卷、bind mount

我见过不止一次这样的对话：“数据不是都在容器里的 /var/lib/mysql 吗？我进容器把整个目录拷出来不就行了？”要真这么简单，迁移就不会有这么多幺蛾子了。

2.1 三分钟搞清楚你的 MySQL 数据到底在哪

容器里的/var/lib/mysql只是一个“容器视角”的路径，它背后可能对应三种完全不同的存储位置。

• 容器可写层：启动时没挂任何卷，数据写在容器内部，docker rm后数据就没了。这种是最危险的部署方式，迁移时只能先docker commit再想办法，非常不推荐长期使用。
• 命名卷（named volume）：由 Docker 管理，物理位置一般在宿主机的/var/lib/docker/volumes/<卷名>/_data。容器删了，卷还在，这是最常见的推荐做法。
• bind mount（绑定挂载）：你手工指定宿主机目录，比如-v /data/mysql:/var/lib/mysql。数据位置一眼能看穿，备份和迁移最方便。

可以打个比方：容器像一间临时办公室，镜像像装修图纸，卷才是真正的文件柜。办公室可以随时推倒重建，但文件柜你要抱走。

2.2 用 docker inspect 反查部署信息

迁移之前必须先确认旧容器属于上面哪种情况。我当时用的是下面这条命令：

docker inspect mysql-server --format '{{json .Mounts}}'

输出大约长这样：

[ { "Type": "volume", "Name": "mysql_data", "Source": "/var/lib/docker/volumes/mysql_data/_data", "Destination": "/var/lib/mysql" } ]

看到Type: volume和Name: mysql_data，就说明用的命名卷，数据落在/var/lib/docker/volumes/mysql_data/_data。如果看到Type: bind，那Source会直接指向你指定的宿主机目录。这两种情况迁移策略差别很大，bind mount 直接压缩宿主目录；命名卷则要先搞清楚 Docker 实际存放路径。

2.3 顺手记录“隐藏”的挂载项

MySQL 镜像通常不止一个数据卷。比如我那个旧容器，除了/var/lib/mysql，还挂了一个配置目录/etc/mysql/conf.d，里面放的是自定义字符集、时区、连接数上限等配置。

如果只盯着数据卷迁移，配置很容易被漏掉。所以我建议把docker inspect里的 Mounts、Env、PortBindings 全部存成一个 json 文件，后面对照着建新容器，一条都不会少。

3. 动手之前先备份：逻辑备份和物理备份怎么选

备份这件事，排在所有操作最前面。很多人觉得“反正我就是要迁移，直接拷过去就行”，但迁移过程中的中断、误操作、版本不兼容，任何一个环节出问题都可能让数据遭殃。

3.1 为什么备份排在所有操作前面

数据库迁移和其他文件搬运最大的区别在于：文件在拷的过程中，数据库可能还在写。直接对着正在运行的 MySQL 数据目录下tar，很可能得到一个不一致的备份，InnoDB 在恢复时会因为 redo log 和表数据对不上而拒绝启动，或者启动后随机丢数据。

所有备份手段的本质，都是解决“一致性问题”。差别在于锁不锁表、停不停库、快不快。

3.2 mysqldump 逻辑备份：适合中小库和跨版本

如果库不大，比如几个 GB 以内，而且你计划跨大版本升级，我强烈建议用mysqldump。它导出的是 SQL 文本，对存储引擎细节不敏感，跨版本兼容性最好。

我当时的导出命令大致是这样：

docker exec mysql-server mysqldump \ --single-transaction \ --quick \ --routines \ --events \ --triggers \ --default-character-set=utf8mb4 \ -uroot -p \ --databases business_db > /backup/business_db.sql

注意几个细节：--single-transaction对 InnoDB 表做一致性快照，不会锁业务表；但 MyISAM 表还是会锁，所以如果有 MyISAM 表，最好还是挑业务低峰。--routines、--events、--triggers分别导出存储过程、事件调度器、触发器，漏了这些，迁移后应用可能跑一半才报错。--databases会把建库语句也带上，新机器上导入时不用手工建库。

3.3 物理备份：适合大库和快速切换

如果你的库到了几十 GB 甚至更大，mysqldump 导出和导入的时间会非常难熬，这种时候物理文件拷贝效率高得多。做法是停掉容器，直接打包整个数据卷。

docker stop mysql-server tar -czf /backup/mysql_data.tar.gz -C /var/lib/docker/volumes/mysql_data/_data .

停库后打包虽然会有一个维护窗口，但对迁移动作来说，停机几分钟换来一致性和省心，非常值。如果完全没有停机窗口，那就得用在线物理备份工具，比如 Percona XtraBackup，原理是复制文件的同时追 redo log，复杂度高不少，中小环境一般不首选。

我自己当时因为业务量不大，但跨版本，所以“双保险”：白天业务低峰做了一次逻辑备份，夜里维护窗口又做了一次停库物理打包。结果特别有用，后面导入出问题时，物理包成了快速恢复的底牌。

4. 场景 A：同版本平迁，用 tar 打包数据卷最省事

如果你的诉求只是“换台机器，MySQL 版本不变”，那最直接的方式就是物理卷迁移：停库、打包、还原、启动，四步走完。

4.1 停机、打包

先停容器，避免复制过程中有新写入：

docker stop mysql-server

然后打包数据卷。注意打包时别把 tar 包放在数据卷目录里面，否则会把包自己也打进去，白白多出一大块体积。我习惯先建一个独立的备份目录：

mkdir -p /backup cd /var/lib/docker/volumes/mysql_data tar -czf /backup/mysql_data.tar.gz -C /var/lib/docker/volumes/mysql_data/_data .

-C是让 tar 先切到_data目录，然后打包当前目录内容。这样还原时解压出来就正好是/var/lib/mysql里该有的文件结构。

4.2 新机器上还原数据卷

把 tar 包传到新机器后，先创建一个同名数据卷：

docker volume create mysql_data

然后我推荐用一个临时容器来解压，而不是直接解到宿主机目录。原因是 Docker 卷的实际存放路径在不同版本、不同系统上可能有差异，让容器来挂载卷可以保证路径绝对正确：

docker run --rm \ -v mysql_data:/target \ -v /backup:/backup:ro \ alpine \ tar xzf /backup/mysql_data.tar.gz -C /target

解压完还要顺手修一下属主。MySQL 官方镜像默认用mysql用户启动，数据目录如果属于 root，启动时可能会遇到权限问题。如果你用的是 alpine/centos 这类临时容器，可以这样处理：

docker run --rm -v mysql_data:/target alpine chown -R mysql:mysql /target

不过如果是官方镜像里自带的 mysql 用户，直接 chown 成mysql:mysql一般没问题。

4.3 新容器启动：不要照抄原来的 -e

这一步是最容易让老手翻船的。很多人看到原来容器启动命令里有-e MYSQL_ROOT_PASSWORD=xxxx，新容器也照抄，结果发现根本没用。原因很简单：MySQL 官方镜像的 entrypoint 脚本只会在数据目录为空时初始化数据库并设置密码；一旦目录里已经有数据，MYSQL_ROOT_PASSWORD等环境变量就会被忽略。

所以启动命令应该这样写：

docker run -d \ --name mysql-new \ -v mysql_data:/var/lib/mysql \ -p 3306:3306 \ mysql:5.7

注意版本要和旧容器保持一致，至少主版本一致。启动后 root 密码还是原来的密码，连接串、账号权限也都在。不要因为密码不匹配就觉得数据丢了，先想想是不是环境变量被忽略了。

5. 场景 B：跨版本升级，mysqldump 逻辑迁移才是正路

我当时是要从 5.7 迁到 8.0，顺便换机器，所以走了逻辑备份路线。整个过程无非三步：导出、传输、导入，但每一步都有细节。

5.1 导出、传输、导入的标准三步

先在旧容器里导出 SQL 文件。注意docker exec后面的重定向是在宿主机 shell 里执行的，不是容器内：

docker exec mysql-server mysqldump \ --single-transaction \ --routines \ --events \ --triggers \ --default-character-set=utf8mb4 \ -uroot -p \ --all-databases > /backup/all_db.sql

然后通过 scp 或 rsync 传到新机器：

scp /backup/all_db.sql user@新机器IP:/backup/

最后在新容器上导入。先把新容器跑起来，再往里面灌数据：

docker exec -i mysql-new mysql -uroot -p < /backup/all_db.sql

这里-i必须加，否则不会把宿主机的标准输入接进容器。

5.2 大库怎么办

如果库比较大，有几个能显著提速的土办法。

第一是压缩传输。导出时直接管道压缩：

docker exec mysql-server mysqldump ... | gzip > /backup/all_db.sql.gz

导入前先解压：

gunzip -c /backup/all_db.sql.gz | docker exec -i mysql-new mysql -uroot -p

第二是导入时调大max_allowed_packet。如果导出的 SQL 里含有较大的 BLOB 字段，默认配置很容易报Packet too large这种错。在启动容器时可以加--max-allowed-packet=1G，或者导入时在 SQL 会话里调整。

第三是关闭 binlog。导入过程会产生大量 binlog 文件，对恢复速度有明显影响。如果新实例是孤立的、不需要主从同步，可以在启动容器时加--skip-log-bin，导入完再改回来。这个操作在新环境独立部署时很常见，但如果有复制链路就不要乱关。

5.3 跨版本时最容易踩的三个坑

从 5.7 升到 8.0，不是执行一遍导入就完事。我自己就遇到几个问题。

第一个是认证插件。MySQL 8.0 默认创建的用户认证插件是caching_sha2_password，但很多旧客户端、旧应用代码只支持mysql_native_password。导入旧库后，账号默认还是原来的插件，但如果迁移过程中新建过用户，就要注意。排查方法：

SELECT user, host, plugin FROM mysql.user;

让旧应用连不上时，基本先查这里。

第二个是sql_mode差异。8.0 默认的sql_mode比 5.7 严格，原来能跑的一些 SQL 到新库可能直接报错，最常见的是ONLY_FULL_GROUP_BY。迁移之后挑几条关键报表 SQL 跑一遍非常重要。

第三个是大小写敏感配置，lower_case_table_names。这个问题最隐蔽：Linux 默认是 0，表名区分大小写；Windows/macOS 默认是 1。如果旧环境表名有大写小写混用，新环境配置不一致，应用访问表时就会报“表不存在”。启动容器时如果需要兼容旧环境，要显式加参数：

docker run -d ... mysql:8.0 --lower_case_table_names=1

注意lower_case_table_names在 8.0 里只能在初始化时设置，我因为图省事，初始化之后再去改，数据库直接拒绝启动，最后只能重新初始化数据目录再导入。

6. 容器本身的配置也要跟着走

数据迁移只是第一步，容器跑起来之后，端口、网络、自启动策略、自定义配置，每一项都决定业务能不能正常接进来。

6.1 提取原容器的完整启动参数

如果你手里没有原来的 docker run 命令或 compose 文件，可以用docker inspect反向提取。我习惯把下面几个字段存下来：

docker inspect mysql-server \ --format '{{.Config.Image}}' \ --format '{{.Config.Env}}' docker inspect mysql-server \ --format '{{json .HostConfig.PortBindings}}' docker inspect mysql-server \ --format '{{.HostConfig.RestartPolicy.Name}}'

有了这几个信息，新容器的启动参数就能拼出来。如果原来部署用的是 Docker Compose，我更建议直接照着旧 compose 文件改，能少踩很多漏配的坑。

6.2 端口映射、网络模式和自启动

端口映射最直接的判断依据是：应用代码里连的是127.0.0.1:3306、宿主机 IP，还是容器名？如果应用也跑在 Docker 里，网络模式就复杂一些，可能要保证新容器加入同一个自定义 bridge 网络，否则容器之间靠服务名访问会断掉。

启动时记得把自动重启策略带上：

docker run -d \ --name mysql-new \ --restart unless-stopped \ --network my_app_net \ -p 3306:3306 \ -v mysql_data:/var/lib/mysql \ mysql:8.0

unless-stopped比always更稳，手动停掉的容器不会被强迫拉起来，重启宿主机后又能自动恢复。

6.3 自定义配置文件不能只迁数据不迁配置

我旧容器里有一个挂载的配置文件，专门设置了character-set-server=utf8mb4、max_connections=500、innodb_buffer_pool_size=4G。这些东西如果没跟着迁，新容器用默认配置启动，后果就是应用写入中文变乱码、业务高峰连接数被打满、内存性能反差明显。

迁移前先看一眼当前字符集相关变量：

SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';

新容器启动时挂载同样的配置目录，命令大致如下：

-v /data/mysql/conf:/etc/mysql/conf.d:ro

配置目录挂上去之后，重启容器再用上一条 SQL 检查，确认字符集和旧环境一致才继续下一步。

7. 迁移完成后的验证与真实踩坑记录

数据导入完、容器跑起来，不等于迁移结束。我见过太多“容器状态是 Up，业务一访问就报错”的情况，所以验证环节必须单独做一遍。

7.1 数据一致性验证的几条硬指标

先做最基础的连通性检查：docker logs里有没有 ERROR，端口监听是否正常，能否用原账号连上。然后对账几个关键指标：

• 核心库的表数量与行数，比如count(*)对比。
• 存储过程、触发器、事件列表是否完整。
• 权限账号清单是否一致。
• 应用连接串配置是否更新到新 IP 或新端口。

我当时的做法是导出一份“迁移前元数据快照”：

docker exec mysql-server mysql -uroot -p -e "show databases;" docker exec mysql-server mysql -uroot -p -e "select user,host from mysql.user;"

新环境导入后逐项对照，比肉眼逐个点页面靠谱得多。

7.2 我亲自踩过的三个坑

第一个坑是直接打包运行中的数据目录。当时图省事，没停容器就tar数据卷，结果迁移到新机器后 MySQL 一直提示需要恢复 redo log，启动了十几分钟没起来。后来回旧机器停库重新打包才解决。这个教训让我后来所有数据库迁移都先停实例再操作。

第二个坑是-e MYSQL_ROOT_PASSWORD不生效。我一开始也是惯性思维，在新容器启动时填了密码，结果应用连的时候一直报密码错误。排查了半天才反应过来，数据目录非空时环境变量根本不参与初始化。最后用原来的密码连，果然直接进去了。

第三个坑是字符集不对导致中文乱码。那次不是数字丢失，而是所有中文备注全变成???。原因就是导出时没有加--default-character-set=utf8mb4，默认用了旧容器里的 latin1 或 utf8mb3。重跑一次带字符集参数的导入才恢复。从那以后我养成了迁移前先查字符集、迁移后先看中文显示的习惯。

7.3 回滚方案：旧容器先别急着删

迁移成功的定义不应该是“新容器能跑”，而是“业务稳定运行一段时间”。我会习惯把旧容器保持原样至少保留三天，不删不关，只停掉端口监听，避免和新的应用进程抢连接。

如果新环境出现问题，想瞬间切回，可以用docker rename处理容器名冲突：

docker rename mysql-new mysql-new-broken docker start mysql-server

不过要提醒一点，回滚后从切换窗口到回滚时间点之间新增的数据可能会丢，所以回滚前如果能再做一次备份最好。这也是为什么我建议迁移动作尽量安排在业务低峰，给自己留足够缓冲时间。

最后分享一个自己的习惯：所有数据库迁移，无论实例多小，我都会先做一次全量备份再动刀。哪怕业务方反复强调“这只是个测试库，没事”，我也坚持备份。原因很简单，真正让你焦头烂额的从来不是数据量，而是你当时觉得“肯定没问题”的侥幸心理。多花十分钟备份，省掉的可能是一整夜的修复。