mysqldump + docker exec 全量备份是最安全可控的起点，必须加--single-transaction、--routines、--events、--triggers、--set-gtid-purged=OFF；物理备份禁用docker commit或直接cp /var/lib/mysql，因易致数据不一致或崩溃恢复失败。
直接用 mysqldump + docker exec 做全量备份，是最安全、最可控的起点；迁移则优先走数据卷打包（tar + --volumes-from），别一上来就推镜像或挂载裸目录。
为什么不用 docker commit 或直接拷贝 /var/lib/mysql？
容器 commit 会把整个文件系统层固化，包含日志、临时文件、甚至失败的 SQL 事务残留，还原后极可能报错 Table 'xxx' doesn't exist 或 InnoDB: Database page corruption。而直接 cp 容器内 /var/lib/mysql 必须先 docker stop，否则备份不一致——InnoDB 崩溃恢复失败率极高，尤其在有写入压力时。
真正安全的物理备份只适用于已停机且确认无未刷盘事务的场景，日常备份请绕开。
mysqldump 全量备份必须加的参数组合
以下参数缺一不可，否则备份结果无法用于可靠还原：
-
--single-transaction：对 InnoDB 表开启一致性快照，全程不锁表（MyISAM 仍会锁，但 MySQL 8.0 默认引擎已是 InnoDB） -
--routines：导出所有CREATE PROCEDURE/FUNCTION，漏掉会导致业务逻辑中断 -
--events和--triggers：若库中用了事件调度器或触发器，必须显式加上，否则还原后功能缺失 -
--set-gtid-purged=OFF：避免 GTID 相关元数据干扰跨版本或单实例迁移
完整命令示例：
docker exec -i mysql-container mysqldump --single-transaction --routines --events --triggers --set-gtid-purged=OFF --all-databases > full_backup_$(date +%Y%m%d_%H%M%S).sql
备份脚本里最容易被忽略的三件事
很多脚本跑着跑着就静默失败，问题往往出在这些“边缘检查”上：
- 容器状态检测：
if ! docker ps --format '{{.Names}}' | grep -q '^mysql-container$'; then echo 'container down'; exit 1; fi—— crontab 不会告诉你容器已退出 - 磁盘空间预警：
if [ $(df /backup | tail -1 | awk '{print $5}' | sed 's/%//') -gt 90 ]; then echo 'disk full'; exit 1; fi—— 备份中途填满磁盘，留下半截损坏文件 - 密码绝不硬编码：
~/.my.cnf文件权限必须是600，内容仅含[client]段，否则mysqldump会拒绝读取
跨主机迁移：用 tar 打包数据卷比推镜像更稳
推镜像（docker commit → docker push）看似方便，但镜像体积大、网络传输慢、且无法跳过中间层校验——一旦某层拉取失败，整个迁移中断。更稳妥的做法是直接打包数据卷：
在源主机执行：
docker run --rm --volumes-from mysql-container -v $(pwd):/backup ubuntu tar cvf /backup/mysql-data.tar /var/lib/mysql
在目标主机启动新容器前，先解压：
docker run --rm -v mysql_data:/var/lib/mysql -v $(pwd):/backup alpine tar xvf /backup/mysql-data.tar -C /
再启动容器时挂载该卷：-v mysql_data:/var/lib/mysql。这种方式不依赖网络仓库、不引入额外镜像层、还原后数据路径与原环境完全一致，适合生产环境快速切换。
注意：tar 打包前确保 MySQL 已停止，或确认该卷只被一个容器独占使用；若正在运行且有写入，仍应优先选 mysqldump 逻辑迁移。
