mysql使用Docker容器迁移与升级数据库的最佳实践

禁止用 docker commit 迁移 MySQL，应采用 mysqldump/mysqlpump/mydumper 逻辑导出或 LVM/云盘快照物理备份；升级版本需先初始化新数据目录再迁移文件，并配置健康检查验证 SQL 可用性及关闭 innodb_stats_on_metadata。

mysql使用Docker容器迁移与升级数据库的最佳实践第1张

用 `docker commit` 迁移 MySQL 数据库？别这么做

直接对运行中的 MySQL 容器执行 docker commit 生成新镜像，再启动——这是最常见也最危险的迁移方式。容器层写入（如 /var/lib/mysql）不会被完整固化进镜像，且二进制日志、InnoDB redo log 状态、表空间一致性全无保障，启动后大概率报 Table 'xxx' doesn't exist 或 InnoDB: Database page corruption。

真正安全的迁移起点，永远是逻辑导出或物理快照：

生产环境优先用 mysqldump + --single-transaction --routines --triggers --events 导出全量（注意字符集显式指定 --default-character-set=utf8mb4）
大库（>50GB）改用 mysqlpump（MySQL 5.7+）或 mydumper（支持并行、断点续传）
若停机窗口极短，可基于 LVM 快照或云盘快照做物理备份，但必须确保 MySQL 处于 FLUSH TABLES WITH READ LOCK + SHOW MASTER STATUS 记录位点后才打快照

升级 MySQL 版本时，`docker run` 的挂载与初始化顺序很关键

从 MySQL 5.7 升到 8.0，不能简单替换镜像标签后挂载旧数据卷就启动。MySQL 8.0 启动时会自动执行 mysql_upgrade 等兼容性检查，但前提是：数据目录必须由目标版本首次初始化过，否则会因系统表结构不匹配而卡在 Starting initialization process... 并反复重启。

正确流程是分两步走：

先用目标版本镜像（如 mysql:8.0）启动一个空容器，挂载空数据卷，让其完成初始化（生成 mysql、sys 系统库和默认用户）
停掉该容器，把旧数据目录（如 /var/lib/mysql）下的 ibdata1、ib_logfile*、所有业务库目录（不含 mysql、performance_schema、sys）复制进去
启动新容器时加参数 --skip-grant-tables 和 --shared-memory（避免权限校验失败），再手动执行 mysql_upgrade -u root -p

注意：MySQL 8.0 默认认证插件改为 caching_sha2_password，应用连接字符串需显式指定 ?serverTimezone=UTC&allowPublicKeyRetrieval=true，否则报 Public Key Retrieval is not allowed。

`docker-compose.yml` 中 MySQL 的健康检查不能只靠 `TCP port`

很多配置用 healthcheck: test: ["CMD", "nc", "-z", "localhost", "3306"]，这只能说明端口通，不代表 MySQL 已完成初始化、系统表可用、甚至可能刚启完正在加载 InnoDB buffer pool。容器编排工具（如 Swarm/K8s）可能在此刻将流量切过去，导致应用连上却执行 SELECT 报 Unknown database 'xxx'。

应改用能验证 SQL 执行能力的检查：

healthcheck:
  test: ["CMD", "mysql", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD", "-e", "SELECT 1"]
  interval: 30s
  timeout: 10s
  retries: 5
  start_period: 40s

其中 $$MYSQL_ROOT_PASSWORD 是 Docker Compose 的转义写法（单个 $ 会被当成 shell 变量展开）；start_period 必须设为 40s 以上，给 MySQL 8.0 的 InnoDB 初始化留足时间（尤其数据量大时）。

跨大版本升级后，`information_schema` 查询变慢？检查 `innodb_stats_on_metadata`

MySQL 5.7 默认开启 innodb_stats_on_metadata = ON，每次查 information_schema.TABLES 都会触发统计信息更新，小库不明显，但升级到 8.0 后若未关闭，会导致 SHOW TABLES、Navicat 刷新库列表等操作卡顿几十秒。

这不是 Docker 特有现象，但在容器里容易被忽略，因为配置常写死在 my.cnf 里，而升级镜像时可能沿用了旧配置。解决方法很简单：