迁移失败怎么回切

迁移失败不丢人，没预案才丢人。切换后发现业务异常，回切的速度取决于切换前留了多少后手，而不是临场的反应。 回切靠三个前提 第一，老环境不能急着销毁。老机至少保留一周，数据目录原样不动，这是回切的全部本钱。第二，DNS 要能快速回指。切换前把 TTL 调到 300，回切时只改一条解析记录，几分钟就能生效全网。第三，切走期间老库别删。哪怕新库已经接管，老库也保持只读留底，出了争议有据可查。老机快到期时先续上费，观察期没过就让它继续跑；为省几天续费把退路断了，是最亏的一种省法。 回切三步 确认要回切后：第一步，域名解析改回老 IP，TTL 已经是 300，几分钟内大部分用户就能回来。第二步，补数据差。切换运行期间新库可能又收了订单和注册，把这段时间新库的增量导出来，导回老库，按表和时间字段圈定范围，避免覆盖老库已有数据。具体按更新时间导：mysqldump 库名 表名 --where="updated_at > '切换时刻'" > delta.sql，导回前先把老库这几张表备份一份。第三步，应用配置改回老库地址，重启服务，把下单和登录再验证一遍。 预案平时就要写 回切步骤要在切换之前写成文档：谁执行、改哪条解析、数据差怎么补、验证哪些接口，一条条列清楚。真出事时人在紧张状态下，是没法现场设计流程的，照单执行才是最快的。提交迁移类工单的时候，把回切预案一并附上，技术侧处理起来也更有针对性。回切完成后新机别急着销毁，异常可能是数据问题也可能是环境问题，留三天方便登进去排查。 回切不是失败，快速止损再择机重迁才是正解。一份迁移方案里没有回切章节，就不算完整方案；老机多开几天的费用，买的正是这份从容。