迁移演练：先在测试机走一遍

正式迁移前先在测试机上走一遍全流程，这个时间花得值。演练的意义不在练手，在于把正式切换的每一步都变成已验证的动作。 演练怎么搭 找一台配置随意的测试机，系统版本尽量贴近生产环境。拿最近一次的全量备份恢复上去：文件解包、数据库导入、环境按清单装好、服务拉起。备份越新，演练越接近实战，暴露的问题也越真实。备份最好拿两份：一份全量、一份切换前一天的增量，正式迁移时数据也是这么组合的，演练顺便验证了备份本身可用。 记时间，别估时间 演练时每个阶段掐表：解包用了多少分钟、导库用了多少分钟、配置加验证用了多少分钟。正式切换的停机窗口，就是拿这些数字往上加两成余量算出来的。"导库大概一两个小时吧"这种说法在窗口承诺里一文不值，“导库实测 47 分钟”才是能签字的数字。掐表用手机就行，更细一点用 time 命令：time mysql -uroot -p 库名 < dump.sql，结束直接报真实耗时。 问题清单是最大产出 演练一定会暴露问题：缺一个 redis 扩展、字符集不一致导致乱码、伪静态规则没生效、某个定时任务依赖的目录不存在。每暴露一个就记一条，附上解决办法。这份问题清单在正式迁移时就是验收单，逐条打钩，一个都不放过。 演练到正式之间的差距 测试机数据量小、没有真实并发，这两点要有预期。涉及大表导入的环节，时间估算要按生产数据量重新折算；并发的部分，交给切换后的压测验证补上。 顺带一个建议：演练通过的整套步骤整理成带命令的文档，正式迁移照着敲。紧张状态下照单执行，永远比自由发挥可靠。 彩排过一遍，正式演出才敢保证不冷场。没做演练的迁移，等于把正式切换当成演练。