MySQL迁移失败后，快速回退的核心是提前准备、分层备份、按序验证。不能等出问题才想怎么撤，得在迁移前就定好“逃生通道”。
一、迁移前必须做的三类备份
回退快不快，取决于备份是否完整、可立即用：
逻辑备份（mysqldump）：导出关键库的结构+数据，带--single-transaction和
--routines，确保一致性；建议压缩存档并校验MD5 物理备份（如xtrabackup）：对整实例做热备，恢复速度远快于逻辑导入，适合大库；备份后执行
xtrabackup --prepare完成预恢复 配置与权限快照：用
SHOW GRANTS FOR 'user'@'host';导出所有账号权限；保存
my.cnf、字符集、sql_mode等关键参数
二、迁移中启用“灰度切换+只读保护”
避免全量切流导致无法回头：
新库初始化完成后，先设为read_only=ON，仅允许迁移工具写入，禁止业务直连 用中间件或DNS逐步切1%~5%流量，观察错误日志、慢查、主从延迟；任一异常立即切回旧库 在旧库执行
FLUSH TABLES WITH READ LOCK;前，确认新库已同步完最后binlog位点（对比
SHOW MASTER STATUS和
SHOW SLAVE STATUS）
三、回退操作清单（按优先级排序）
一旦确认迁移失败，按以下顺序执行，跳过耗时环节：
立刻将业务流量切回旧库（修改应用配置或DNS，5分钟内生效） 若新库有写入，用mysqlbinlog解析新库binlog，反向生成undo SQL（注意事务边界），或直接丢弃新库 小库（mysqldump备份恢复：
mysql -u root old_db大库（>50GB）直接用xtrabackup物理恢复：停新库→删datadir→拷贝备份→chown→启动；全程可控制在20分钟内 最后一步：还原账号权限、检查时区/字符集、验证连接池配置是否匹配旧库
四、自动化回退脚本要点
手动操作易出错，建议封装基础回退脚本：
脚本开头校验：旧库是否存活、备份文件是否存在、磁盘空间是否充足 区分场景自动选路：数据量 每步加set -e和日志记录，失败时自动发送告警（如钉钉Webhook） 包含“干运行模式”（
--dry-run），输出将执行的命令但不真正执行
迁移不是单次动作，而是一套带保险绳的流程。备份没验过等于没备，回退脚本没跑过等于没写。真正决定成败的，是迁移窗口前那半小时的 checklist 执行质量。
