凌晨三点，手机在床头柜上疯狂震动。我迷迷糊糊摸过来一看，运维群里炸了锅——数据库CPU跑到99%，慢查询堆积如山，整个后台系统像被掐住脖子一样喘不过气。那会儿我们还在用自建的MySQL集群，三台物理机撑着全部业务，磁盘快满了，主从复制延迟从几秒飙升到几分钟。这不是第一次出状况了，但那次特别凶。老板第二天丢给我一句话：“上云，迁RDS，别整出故障。”
真正动手迁移，才知道“零停机”这三个字有多重。网上教程一搜一大把，什么“三步迁移”“五分钟切换”，看得人头皮发麻。但真到生产环境，你面对的是一个跑了三年、里面有上亿条订单记录的数据库，稍微手抖一下，可能就是一场事故。我花了整整一周做方案，定下来的路子是：先把自建库的数据全量备份，再用DTS（数据传输服务）做增量同步，在业务低峰期做切换。听着简单，里面全是坑。
先说全量备份。我那会儿用mysqldump导数据，3亿多条记录，导了快十个小时。导完一比对，发现数据量对不上——差了十几万条。查了半天，原来是业务那边有个定时任务，每五分钟清理一次过期数据，导出过程中数据一直在变。这个坑提醒了我：全量导出必须配合增量同步，否则时间窗口拉得越长，数据差异越大。后来我改用物理备份，直接拷贝数据文件，速度快了不止一倍，但前提是源库和目标库的版本、配置得兼容。RDS这边支持从自建MySQL直接迁移，但版本跨度别太大，建议先小版本升级再迁。
增量同步这块，DTS确实省心，但也不是开了就完事。我遇到过同步延迟飙升，一查是源库的binlog格式没开对，DTS读不到完整的事件。还有一次，目标库的字符集和源库不一致，导致中文乱码，业务那边直接炸了。所以配置DTS之前，先把源库的binlogrowimage设为FULL，把charactersetserver统一成utf8mb4，这些细节不注意，后面全是眼泪。另外，同步任务建好之后，别急着切，让它跑个两三天，观察延迟是否稳定在几秒以内，数据校验工具（DTS自带的数据比对功能）多跑几遍，确认无误再谈切换。
切换是整个过程中最刺激的环节。我选了个周日凌晨两点，业务量最小的时候。操作步骤看起来简单：先停掉写入，确认DTS同步延迟归零，然后把应用连接池的地址改成RDS的域名，重启应用。但实际操作中，我遇到了连接池缓存的问题——应用那边有几百个长连接一直挂在旧的数据库地址上，改了配置也没用，得等连接超时才能释放。后来我干脆在切换前先把应用集群的流量摘掉，等连接全部断开，再改配置，重新挂流量。整个过程花了大概十五分钟，业务侧的表现是：有几次请求超时重试，但没有一条数据丢失。
切换成功只是第一步，验证才是重头戏。我做了三件事：第一，跑一遍核心业务的自动化测试用例，确保增删改查都正常；第二，对比切换前后的关键监控指标，比如QPS、响应时间、慢查询数量；第三，把RDS的备份策略打开，每天自动快照，加上binlog保留七天，这样万一出问题还能回滚。这里有个容易被忽略的点：RDS虽然是托管服务，但备份和恢复的演练你得自己测。我见过有人迁完RDS，以为万事大吉，结果半年后误删了一张表，才发现恢复流程从来没跑通过。
说到成本，RDS确实比自建要贵，但算总账未必亏。以前自建集群，光运维人力就占了一个人的一半工作量，更别说硬件折旧和机房带宽。迁到RDS之后，自动主备切换、监控告警、一键扩容，这些以前要手动折腾的事情全变成了控制台里的几个按钮。我们后来赶上一次大促，流量翻了五倍，RDS自动做了只读实例的扩展，全程没惊动开发，这想都不敢想。
回头看看这次迁移，最大的感悟是：零停机不是靠运气，是设计出来的。你得把每个环节的风险都提前想清楚，全量备份怎么做、增量同步怎么追、切换窗口怎么选、回滚预案怎么备，每一步都得有Plan B。而且，别迷信“自动化一键迁移”，工具能帮你省力气，但决策还得自己拿。比如什么时候切、怎么切、切完怎么验证，这些判断力，比工具本身值钱。
说句实在的，RDS切换这件事，干过一次就不慌了。但每次听到别人说“迁移很简单”，我都会想起那个凌晨三点的手机震动。数据是命根子，数据库是命根子的保险箱，动保险箱的时候，手得稳，心得更稳。现在RDS的生态越来越成熟，工具链也完善，但该踩的坑一个都少不了。把这篇实战经验留着，等你真正要迁的时候，翻出来看看，至少能少走几步弯路。
