回滚前必须确认三件事：一是有可用、一致、可验证的备份；二是备份类型适配（物理备份优于逻辑导出，mysqldump无法还原mysql系统库权限）；三是datadir未被覆盖。
回滚前必须确认的三件事
MySQL 升级或迁移失败后不能直接“倒车”，回滚是否可行，取决于你有没有提前准备。最关键的判断点是：是否有可用的、一致的、可验证的备份。没有它，所谓回滚只是重装或数据抢救。
常见错误现象包括：mysqld 启动失败报 Table 'mysql.user' doesn't exist、Unknown table engine 'InnoDB'、或升级后客户端连上但查询返回 ERROR 1932 (HY000)。这些往往意味着系统表损坏或版本不兼容，此时依赖备份恢复是唯一稳妥路径。
- 确认备份类型：物理备份（如
mysqldump或Percona XtraBackup）比逻辑导出更适配快速回滚；仅靠mysqldump --all-databases无法还原mysql系统库权限结构，尤其在跨大版本时 - 验证备份可用性：用
mysqlcheck --check --all-databases或导入到测试实例跑一次SELECT 1 FROM mysql.user LIMIT 1 - 检查
datadir是否被覆盖：若迁移脚本执行了cp -r或rsync --delete，原数据可能已不可逆丢失
使用 mysqldump 备份回滚的具体步骤
适用于小规模实例（5GB 以下）、且备份含 --single-transaction --routines --triggers --events 参数的情况。注意：它不能还原 MySQL 用户密码哈希（8.0+ 使用 caching_sha2_password 插件时需额外处理）。
实操要点：
- 停掉新版本
mysqld，确保无写入；启动旧版本服务（如mysqld-5.7），指定原datadir和配置文件 - 清空当前库（非必须，但避免冲突）：
mysql -u root -e "DROP DATABASE IF EXISTS test; CREATE DATABASE test CHARACTER SET utf8mb4;" - 导入前先关闭外键检查：
mysql -u root -e "SET FOREIGN_KEY_CHECKS=0;"，再执行mysql -u root - 若备份不含
mysql库，需手动重建用户：用旧版mysql_upgrade（5.7）或从mysql_system_tables.sql初始化，否则登录会报Access denied for user
Percona XtraBackup 物理回滚的关键限制
这是最接近“秒级回滚”的方式，但极易踩坑。XtraBackup 不是万能快照工具——它只保证备份时刻的数据一致性，不保证跨版本兼容性。
典型问题场景：
- 从 8.0 备份恢复到 5.7：直接启动会报
InnoDB: Unsupported redo log format，因为 8.0 默认启用innodb_redo_log_encrypt和新日志格式，5.7 完全无法识别 - 备份时用了
--apply-log-only但没做--prepare最终步骤，恢复后ibdata1仍处于“crash recovery pending”状态，mysqld拒绝启动 -
innodb_page_size在备份与目标实例不一致（如备份是 16K，目标是 4K），恢复后表空间无法加载，错误为Tablespace is missing for table
安全做法：只在同一主版本内回滚（如 5.7.35 → 5.7.30），且恢复前用 xtrabackup --version 和 mysqld --version 核对 ABI 兼容性。
跳过崩溃恢复强行启动的风险操作
当 mysqld 卡在 InnoDB: Starting crash recovery 且日志显示 Page directory corruption 时，有人会尝试加 --innodb-force-recovery=6 强启导出数据。这非常危险。
这样做可能：
- 导出部分表成功，但
mysql.user表损坏导致后续无法授权，或information_schema返回空结果 - 强制跳过 undo log 后，事务可见性被破坏，
SELECT可能读到已删除行或丢失更新 - 一旦写入发生（哪怕只是
FLUSH LOGS），数据库将彻底进入不可预测状态，备份失效
真正该做的是：停止所有尝试，从最近一份未损坏的 xbstream 流备份或 mysqldump 中恢复。时间花在验证备份上，远少于事后修复逻辑错乱的数据。
