生产环境必须同时做逻辑和物理备份，仅靠mysqldump或xtrabackup均不可靠；需规范参数、验证兼容性、校验完整性并人工抽检备份文件。
备份必须同时做逻辑 + 物理两套
只靠 mysqldump 不够，只靠 xtrabackup 也不行。生产环境迁移出问题时，90% 的回滚失败都源于备份单一——要么逻辑备份损坏无法导入，要么物理备份版本不兼容没法启动。
-
mysqldump备份要加--single-transaction（InnoDB）、--default-character-set=utf8mb4、--set-gtid-purged=OFF（GTID 环境下），导出后立刻用head -n 5 backup.sql确认首行含/*!40101 SET @OLD_CHARACTER_SET_CLIENT= */ -
xtrabackup必须在源容器内执行，且目标 MySQL 版本号小数点后位数要一致（比如 8.0.33 → 8.0.33 可行，→ 8.0.37 可能失败），备份后运行xtrabackup --prepare验证可启动性 - 两个备份文件必须存不同路径，且带时间戳和校验和：
sha256sum backup.sql xtrabackup_20260810.tar.gz
回滚不是“还原备份”四个字那么简单
回滚动作本身耗时远超预期，尤其当目标库已写入新数据或结构变更后。真正有效的回滚方案必须提前验证路径，而不是等失败了再临时拼凑。
- 逻辑备份回滚：不能直接
mysql -u root -p 。必须先 <code>DROP DATABASE IF EXISTS xxx，再CREATE DATABASE xxx CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci（注意 collation 要和源库完全一致，8.0 默认不是utf8mb4_general_ci） - 物理备份回滚：需停掉目标容器，清空
/var/lib/mysql，复制备份目录并chown -R mysql:mysql /var/lib/mysql，否则启动报Tablespace is missing for table - 回滚脚本必须包含前置检查：比如确认目标容器名、端口、root 密码是否匹配，以及
docker ps | grep mysql是否存在同名冲突容器
跨 Docker 主机迁移时，docker cp 不可靠
大备份文件（>2GB）用 docker cp 传输容易中断且无校验，恢复时发现 SQL 文件末尾截断却毫无提示——这是最隐蔽的故障源头。
- 改用
rsync -avz --partial --progress从源宿主机同步到目标宿主机，支持断点续传 - 若必须用容器内操作，导出时就压缩：
docker exec mysql-source sh -c "mysqldump -u root -p'xxx' --all-databases | gzip" > backup.sql.gz，再gunzip -c backup.sql.gz | docker exec -i mysql-target mysql -u root -p'xxx' - 禁止把备份文件挂载进容器再执行导入——Docker 卷权限和 SELinux 可能导致
Permission denied或静默失败
别忽略系统库和用户权限的兼容性陷阱
MySQL 8.0 默认用 caching_sha2_password 插件，但 5.7 或某些云托管 MySQL 实例不支持该插件，直接导入会卡在 CREATE USER 报错。
- 导出时显式指定认证方式：
mysqldump -u root -p --all-databases --skip-routines --skip-events --ignore-database=mysql --default-auth=mysql_native_password - 导入前检查目标库版本：
docker exec mysql-target mysql -V，若为 5.7，需在导入 SQL 开头手动加SET default_authentication_plugin = 'mysql_native_password'; -
information_schema和performance_schema绝对不要导出——它们是只读视图，强行导入会报错且无意义
backup.sql 扫一眼中间是否有 INSERT INTO `user` 语句、是否有大量乱码、最后几行是不是完整的 );。这一步花不了两分钟，但能避开 70% 的还原失败。
