服务器迁移血泪史：那些让我崩溃的坑，你踩过几个？

52JinY 助手

上周终于把公司老项目从阿里云迁到腾讯云了，整个过程前后折腾了快一个月，踩的坑多到我现在回想起来还觉得头皮发麻。趁着记忆还新鲜，赶紧记录一下，也给后来人提个醒。

最大的坑其实是数据库迁移。我们用的MySQL 5.7，原本以为直接导出导入就行，结果发现字符集编码不一样。老服务器用的latin1，新服务器默认utf8mb4，导致中文数据全乱码。更要命的是我们有几张表混用了多种字符集，迁移的时候根本没注意到这个细节。后来不得不写脚本逐表检查字符集，再用mysqldump加上特定参数重新导出，前前后后搞了三天。现在想想当初建库的时候要是规范一点，也不至于在迁移时候被反噬。

第二个坑是IP白名单的问题。我们系统对接了好几个第三方服务，支付、短信、物流接口什么的，这些服务都绑定了老服务器的出口IP。迁移之前我列了个清单，以为改完就没事了，结果上线当天支付功能直接挂了。后来查日志才发现，有个老接口我们已经半年没用过，文档里都没记录，但代码里还在调用。那个供应商的客服周末不上班，只能紧急回滚，白白浪费了一个迁移窗口期。

还有一个很隐蔽的坑是磁盘IO性能。新服务器配置看起来比老的强，CPU和内存都升级了，但我们忽略了存储类型。老服务器用的本地SSD，新的为了省钱选了云硬盘。结果项目跑起来之后，凡是涉及大量文件读写的任务，性能直接腰斩。尤其是我们有个日志分析脚本，以前跑十分钟，现在要半小时。发现问题后赶紧换成高性能云盘，成本一下子上去了，之前算的账完全白算。

网络配置也让我栽了跟头。两个服务器在不同的VPC里，内网不互通，我以为改成公网访问就行。结果带宽费用暴涨不说，延迟还高得离谱。后来才知道应该用对等连接或者VPN打通内网，但配置这些又花了好几天时间，期间业务只能凑合着用公网扛。

最后一个想说的是监控和告警。迁移之前我把老服务器上的监控脚本都拷过去了，觉得万无一失。结果新服务器的系统版本不一样，有些命令的输出格式变了，监控脚本全部失效。上线第一周基本处于裸奔状态，全靠人工盯着，累得够呛。后来痛定思痛，直接接入了云厂商的监控服务，虽然多花点钱，但省心太多了。

总结下来就是一句话：迁移之前一定要做充分的预演和测试，千万别觉得"应该没问题"。每一个细节都可能成为定时炸弹，等到线上爆炸的时候，后悔都来不及。