先交代一下背景我手头有套内部系统的业务库一直跑在 Docker 容器里最近宿主机要退役必须把 mysql 容器和数据一起迁到新机器。一开始我下意识觉得docker 迁移 mysql 容器不就是把镜像导出、到新机器导入再跑起来等真上手才发现容器迁移里最大的坑从来不是“容器”本身而是数据、权限、字符集、启动方式这些藏在后面的细节。这篇文章就把我当时完整走的流程、做的判断和踩过的教训写出来希望能帮准备做这件事的人少走几个来回。我不打算讲一堆高深理论核心就是三件事搞清楚数据到底放在哪选对迁移方式容器启动配置跟着走。无论你是运维还是开发只要接手过“当年别人随手跑起来、之后再也没人动过”的 mysql 容器这篇应该都会对你有用。1. 先想明白你要迁的是数据不是容器很多人在迁移 docker 容器时第一反应是docker export、docker commit或者把整个容器镜像打包带走。对无状态服务这招偶尔能行但对 MySQL 这种有状态服务方向一开始就偏了。1.1 容器本身根本不值得“迁移”Docker 容器的设计初衷就是“用完即弃”镜像只负责提供程序运行环境容器是一个可读写层每次docker run都是干净的副本。你完全可以在新机器上拉同一个 MySQL 镜像再跑一个新容器没必要把旧容器一层层原封不动搬过去。真正需要跟着搬的是两类东西一类是数据也就是 MySQL 的库表文件另一类是运行参数比如端口映射、环境变量、自定义配置、自动重启策略。换句话说迁移的本质是“把数据和配置搬运到新容器”而不是“把容器搬过去”。1.2 三种迁移诉求对应完全不同的做法我开始动手前先问了自己一个问题这次迁移到底属于哪种场景不同场景方法完全不同。场景典型情况推荐方式同机容器重建容器被删了、启动参数错了、想换镜像版本确保数据卷还在重新docker run挂载即可跨机器迁移版本不变宿主机下线、机房迁移、磁盘扩容物理数据卷打包或 mysqldump 逻辑导出跨 MySQL 大版本升级5.7 迁到 8.0顺便换机器优先 mysqldump 逻辑备份物理文件不能直接通用我这次属于典型第三种新机器没有旧镜像而且想顺手把 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-setutf8mb4 \ -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_PASSWORDxxxx新容器也照抄结果发现根本没用。原因很简单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-setutf8mb4 \ -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-packet1G或者导入时在 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_names1注意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.0unless-stopped比always更稳手动停掉的容器不会被强迫拉起来重启宿主机后又能自动恢复。6.3 自定义配置文件不能只迁数据不迁配置我旧容器里有一个挂载的配置文件专门设置了character-set-serverutf8mb4、max_connections500、innodb_buffer_pool_size4G。这些东西如果没跟着迁新容器用默认配置启动后果就是应用写入中文变乱码、业务高峰连接数被打满、内存性能反差明显。迁移前先看一眼当前字符集相关变量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-setutf8mb4默认用了旧容器里的 latin1 或 utf8mb3。重跑一次带字符集参数的导入才恢复。从那以后我养成了迁移前先查字符集、迁移后先看中文显示的习惯。7.3 回滚方案旧容器先别急着删迁移成功的定义不应该是“新容器能跑”而是“业务稳定运行一段时间”。我会习惯把旧容器保持原样至少保留三天不删不关只停掉端口监听避免和新的应用进程抢连接。如果新环境出现问题想瞬间切回可以用docker rename处理容器名冲突docker rename mysql-new mysql-new-broken docker start mysql-server不过要提醒一点回滚后从切换窗口到回滚时间点之间新增的数据可能会丢所以回滚前如果能再做一次备份最好。这也是为什么我建议迁移动作尽量安排在业务低峰给自己留足够缓冲时间。最后分享一个自己的习惯所有数据库迁移无论实例多小我都会先做一次全量备份再动刀。哪怕业务方反复强调“这只是个测试库没事”我也坚持备份。原因很简单真正让你焦头烂额的从来不是数据量而是你当时觉得“肯定没问题”的侥幸心理。多花十分钟备份省掉的可能是一整夜的修复。
