Docker 部署 MySQL 容器时，最简单的启动命令往往不包含数据卷挂载参数，比如 docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0。这类容器一旦被删除，可写层里的数据就会随容器一起消失。可是实际工作中容器删除、启动失败、误操作等情况经常发生，如果在操作前先搞清楚容器当前状态、数据落盘位置以及备份情况，很多数据其实仍有挽回余地。恢复步骤不是统一的，需要根据容器是否存活、是否配置数据卷、是否开启 binlog、是否有逻辑备份来做不同处理。下面按场景拆开说明。
一、先确认容器状态与数据持久化位置
恢复前第一步是查看容器的状态，特别是已经退出的容器。执行 docker ps -a 可以列出所有包含停止状态的容器，如果 MySQL 容器还在，只是状态为 Exited，那么第一时间不应该删除或重建容器，而是先尝试启动。
docker ps -a docker inspect mysql
接着重点查看 Mounts 字段，它能说明数据是否写到宿主机上。常见的持久化方式有三种：命名卷、绑定挂载和完全无持久化。命名卷的 Mountpoint 通常位于 /var/lib/docker/volumes/ 下，例如 /var/lib/docker/volumes/mysql_data/_data；绑定挂载则直接指向宿主机目录，比如 /opt/mysql_data。如果 Mounts 为空，说明容器没有挂持久化存储，数据只存在于容器可写层。可写层在容器删除时会被清理，但容器停止期间仍然保留，所以即便没有 volume，只要容器没删，也可以先把数据拷贝出来。
可以通过 docker diff mysql 查看容器文件系统相对镜像的变更，粗略判断哪些路径有新增数据。对于没有卷的 MySQL 容器，数据文件通常位于 /var/lib/mysql，执行 docker cp mysql:/var/lib/mysql /tmp/mysql_backup 可以把数据目录完整取出来。需要注意复制前最好停止 MySQL 服务，否则文件可能处于不一致状态。如果容器已经删除，则这条路径基本不可用，必须依赖卷或备份。
二、容器还在但无法启动的修复方法
对于还在但无法启动的容器，先看日志是最高效的定位手段。执行 docker logs mysql --tail 200 查看最近的错误输出。MySQL 启动失败常见原因包括：端口被宿主机其他进程占用、my.cnf 配置错误、数据目录权限不匹配、以及 InnoDB 表空间损坏。端口冲突的日志通常包含 Address already in use；配置错误会提示 unknown variable；权限问题会看到 Permission denied 或 Operating system error number 13。
如果日志提示是数据目录权限问题，多数是宿主绑定目录的属主与容器内 MySQL 进程用户不一致。MySQL 官方镜像中的 mysql 用户 UID 通常是 999，可以通过 chown -R 999:999 /opt/mysql_data 来修正宿主目录属主。如果是 my.cnf 配置错误，可以先把错误配置注释掉，或者挂载一个最小配置重新启动，待数据导出后再调整。
docker logs mysql --tail 200 chown -R 999:999 /opt/mysql_data
当日志中出现 InnoDB: Unable to lock ./ibdata1 或类似表空间错误时，往往是因为上一次容器被强制关停，导致共享表空间没有正常同步。此时可以尝试以 innodb_force_recovery 模式启动。该参数取值范围为 1 到 6，数值越大强制程度越高，4 及以上会跳过部分完整性检查，但可能无法执行写操作。通常先设置 1 或 2，如果仍无法启动再逐步提高，目标只是把数据导出，不建议长期使用该模式运行生产库。
docker run -d --name mysql_recovery \ -p 3307:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ -v mysql_data:/var/lib/mysql \ mysql:8.0 \ --innodb_force_recovery=3
注意上面的命令用到了 mysql_data 这个命名卷，如果原容器用的是绑定目录，则要把 -v mysql_data:/var/lib/mysql 替换成宿主目录路径。启动后如果能读数据，应立即用 mysqldump 将数据导出到逻辑备份，再重建一个正常的容器并导入。
三、容器被删除但数据卷或备份还可用
如果容器已经被删除，但删除时没有加 -v 选项，命名卷通常不会被自动清理。执行 docker volume ls 可以看到保留的卷，用 docker volume inspect vol_name 能拿到 Mountpoint 的真实路径。这种情况下要恢复并不复杂：新建一个 MySQL 容器，把原来的卷挂载到同一路径 /var/lib/mysql 即可。
docker volume ls docker volume inspect mysql_data
如果原数据在绑定挂载目录中，比如宿主机的 /opt/mysql_data，那么容器删除根本不会影响该目录里的文件。只需要启动新容器时再次通过 -v /opt/mysql_data:/var/lib/mysql 挂载即可。需要特别留意的是，新建容器的 MySQL 大版本最好与原容器保持一致，例如原来使用 MySQL 8.0，就不要直接挂到 MySQL 5.7 容器中，否则数据字典和系统表结构不兼容，可能无法启动。
对于一些已经做过逻辑备份的场景，恢复重点则变成如何快速导入。假设手头有 backup.sql 文件，先将文件放入容器可访问的位置，再执行导入。下面示例把宿主机当前目录的备份文件导入到名为 mysql_new 的容器中。
docker exec -i mysql_new mysql -uroot -p123456 < backup.sql
上面的命令中 < 是标准输入重定向，必须先通过 docker cp backup.sql mysql_new:/tmp/backup.sql 拷贝进容器再执行 docker exec mysql_new sh -c 'mysql -uroot -p123456 < /tmp/backup.sql' 也可以。逻辑备份的优点是不依赖文件系统结构和 MySQL 版本，缺点是通常只包含数据，恢复前还需要手动创建数据库和用户权限。
四、物理数据目录复制与注意事项
物理恢复通常指直接拷贝 MySQL 数据目录，而不是导入 SQL 文件。这种方式速度快，适合大数据量，但一致性要求高。对于 InnoDB 引擎，数据目录不是简单的若干 .ibd 文件，还包括共享表空间 ibdata1、重做日志 ib_logfile0 和 ib_logfile1、缓冲池文件等。恢复时必须完整复制整个数据目录，而且最好在 MySQL 停止状态下操作。如果只拷贝部分 .ibd 文件，很可能因为缺少事务信息而无法读取。
如果已经从原容器中把完整 /var/lib/mysql 目录复制出来，恢复到新容器时可以把它挂载为 /var/lib/mysql，但启动前确认目录属主为 UID 999。若复制到 Windows 或某些文件系统后丢失了属主信息，需要重新执行 chown -R 999:999。另外，如果原实例开启了 innodb_file_per_table，每个表会有一个 .ibd 文件，但这不代表可以单独拎出一个 .ibd 文件直接塞到另一个实例里。跨实例迁移单个表需要使用 ALTER TABLE ... IMPORT TABLESPACE，并且需要对应的 .cfg 文件，操作复杂且容易出错。
如果线上环境需要频繁做物理备份和恢复，更推荐使用 Percona XtraBackup。它支持在线热备份 InnoDB，会在备份过程中保持数据一致性，恢复时执行 xtrabackup --prepare 后再复制到数据目录。相比手工停库复制，XtraBackup 更适合并发写入场景强的业务。
xtrabackup --backup --target-dir=/backup/full --user=root --password=123456 xtrabackup --prepare --target-dir=/backup/full
五、binlog 增量恢复与最终验证
如果只恢复了某个时间点的全量备份，而故障前有过增量数据变更，就可以借助 binlog 把缺口补上。前提是原实例开启了 binlog，并且 binlog 文件也被保留下来。查看 binlog 列表可以用 SHOW BINARY LOGS;，查看当前写入位置用 SHOW MASTER STATUS;。恢复时通过 mysqlbinlog 工具把指定区间的日志转换成 SQL，再导入到恢复实例。
mysqlbinlog --start-datetime="2024-01-01 00:00:00" \ --stop-datetime="2024-01-02 00:00:00" \ /var/lib/mysql/mysql-bin.000001 > /tmp/inc.sql
上面命令中的 > 在 HTML 源码里如果放在 pre 块中需要转义，否则会被解析为标签。实际上在 Linux 终端中执行时不需要修改，但在本文展示时为了保证 HTML 格式正确，代码块内已经做了转义处理。增量 SQL 导入前建议先在一个临时库中试跑，确认没有语法错误，再导入正式库。
恢复完成后不能只看导入过程没有报错，还要做数据验证。可以用 SELECT COUNT(*) 对比核心表行数，用 CHECKSUM TABLE 校验表内容，也可以抽查最近几条业务数据的时间戳是否连续。最后再看 docker logs mysql_new 中是否还有 InnoDB 报错，同时确认端口监听正常。如果条件允许，让应用层发起一次只读查询，观察返回结果是否符合预期。
六、避免再次踩坑的持久化与备份策略
很多恢复工作是因为最开始启动容器时没有加数据卷参数。为了减少同类问题，建议统一使用 docker-compose 编排 MySQL，把数据目录、配置文件和备份路径显式声明出来。下面是一个最小示例。
services:
mysql:
image: mysql:8.0
container_name: mysql_prod
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: "123456"
ports:
- "3306:3306"
volumes:
- mysql_data:/var/lib/mysql
- ./backup:/backup
command:
- --log-bin=mysql-bin
- --server-id=1
- --binlog-format=ROW
volumes:
mysql_data:
有了明确的卷定义和 binlog 开启配置，后续的恢复就会简单很多。定期逻辑备份也很重要，可以使用 mysqldump --single-transaction --all-databases 生成一致性快照，再配合 cron 或脚本定时执行。备份文件不要只放在宿主机当前目录，最好同步到对象存储或另一台机器，否则宿主机磁盘故障时备份也会一起丢失。
总结起来，Docker 环境下的 MySQL 恢复顺序应该是：先查容器和卷状态，再决定走启动修复、卷挂载、逻辑导入或物理复制中的哪条路径。只要数据没有完全随可写层删除，或者有任意一种备份存在，就还有恢复空间。恢复完成后立即补全备份和监控，比事后补救更重要。