mysql迁移失败回滚需提前准备、分层备份、按步骤逆向操作；须依赖迁移前快照或sql导出，确认失败阶段后立即停写入、查日志、设只读，并依迁移方式（如mysqldump）执行对应还原。
MySQL迁移失败后，回滚的关键在于提前准备、分层备份、按步骤逆向操作。不能直接“一键回滚”，必须依赖迁移前的快照、SQL导出或主从状态，否则数据可能丢失或不一致。
确认迁移失败点，停止后续操作
先判断失败发生在哪个阶段：是结构同步中断、数据导入卡住、还是应用切换后报错？立即停止所有写入流量（如关闭应用连接池、设置数据库只读），防止新数据写入导致回滚时冲突。
- 检查 MySQL 错误日志（/var/log/mysql/error.log 或 SHOW ENGINE INNODB STATUS）定位具体错误
- 运行 SELECT @@read_only; 确认目标库是否已设为只读，避免误写
- 若使用了 GTID 或 binlog 复制，用 SHOW SLAVE STATUS\G 查看复制是否已断开
根据迁移方式选择对应回滚路径
不同迁移方式回滚逻辑差异大，不能混用：
- mysqldump 全量迁移失败：直接还原迁移前的备份文件（mysql -u root db_name ），前提是该备份已验证可恢复
- Percona XtraBackup 物理迁移失败：用备份时生成的 xtrabackup_binlog_info 定位位点，将源库按该位点启停备库，或直接替换 datadir（需停库）
- 在线DDL或pt-online-schema-change中途失败：工具通常会自动清理临时表和触发器；若未自动清理，手动删掉 _table_name_new 和相关触发器，再检查原表完整性
- 主从切换类迁移（如MHA、Orchestrator）失败：立刻切回原主库，重置从库指向原主，并跳过故障事务（SET GLOBAL sql_slave_skip_counter = 1 谨慎使用）
验证回滚后的一致性与可用性
回滚不是执行完命令就结束，必须验证数据是否真实回到迁移前状态：
- 对比关键表行数：SELECT COUNT(*) FROM table_a; 在新旧库分别执行并比对
- 抽样校验主键范围和字段值，尤其关注时间戳、金额、状态字段是否被意外更新
- 重放最近的 binlog（用 mysqlbinlog --start-datetime）确认回滚后无残留写入
- 启动应用前，先用测试连接连回原库，跑通核心查询和事务流程
预防下次迁移失败的核心动作
一次回滚暴露的是流程漏洞，不是技术问题：
- 每次迁移前强制做 mysqldump --single-transaction --routines --triggers 并校验 checksum
- 在非生产环境完整走一遍迁移+回滚演练，记录耗时与卡点
- 迁移脚本中加入预检项（如磁盘空间、字符集兼容性、外键约束状态）和自动暂停机制
- 把迁移窗口控制在业务低峰期，并预留至少 30% 时间作为缓冲和回滚专用时段
