上周三凌晨两点十七分，我把一组增量备份的校验和敲进终端，屏幕上跳出绿色的OK字样。那一刻，悬了四十八小时的心才真正落回肚子里。这是今年第三次数据库迁移，前两次都出了不大不小的岔子，一次丢了三小时的订单记录，另一次把生产环境的字符集搞乱了，前端页面全是乱码。所以这次，我把自己关在办公室里，把整个流程拆成颗粒度极细的步骤，像拆炸弹一样对待每一次敲击键盘。
数据库迁移这事儿，最要命的是你永远不知道风险藏在哪个角落。你以为把数据文件拷贝过去就完事了，但实际跑起来，可能因为一个索引碎片、一段未提交的事务、甚至某个表的自增主键计数器没同步，就让整个系统在用户面前表演一场灾难。我见过最离谱的一次，是同事把MySQL的data目录整个tar打包，拷到新机器上解压，结果因为版本从5.7跳到8.0，默认的认证插件变了，所有应用连接全部报错，那叫一个酸爽。
所以第一步，永远是把现状摸清楚。别急着动手，先花半天时间梳理你手头到底有哪些库、哪些表、哪些存储过程、哪些定时任务。用一条SQL把所有库的清单拉出来，再对比应用配置里的连接串，看看有没有漏网的。我有一次就漏了一个日志库，那库不大，但里面存着审计记录，合规检查的时候差点出事。还有那些藏在crontab里的备份脚本、数据清洗任务，它们引用的库名和表名，也得逐一确认。
接下来是评估迁移窗口。很多人以为半夜操作就万事大吉，但得看你的业务是啥。如果是电商，凌晨两点到六点确实是低谷；但如果你做的是面向海外的SaaS，那半夜可能是别人的高峰。我这次迁移前，专门让运维拉了一周的QPS曲线，发现我们平台凌晨三点到五点确实没什么流量，才敢把切换时间定在那会儿。另外，还得考虑数据量。几个G的库和几个T的库，迁移策略完全不一样。小库可能停机半小时就完事，大库就得用增量同步加binlog追平的手段，否则停机时间长得能让你接到老板的电话。
说到增量同步，这是整个迁移里最讲究技术含量的环节。我的做法是，先在旧库上开启binlog，并且确认binlog_format=ROW，这样记录的是每一行的实际变化，而不是SQL语句，恢复的时候不容易出偏差。然后搭建一个从库，让它先追上主库的进度，再把这个从库作为新库的基础。整个过程里，最怕的是主从延迟。我见过有人用pt-table-checksum去校验一致性，结果发现延迟了十几分钟，导致数据对不上。所以我的习惯是，在正式切换前两小时，把从库的延迟监控打开，阈值设成五秒，一旦超过就立刻报警，宁可推迟切换也不能带着隐患上线。
切换本身，讲究的是快和稳。我采用的方式是先停写，再同步，切换读。具体来说，就是先把应用里的写操作摘掉，比如通过配置中心把写库的开关关掉，只保留读流量打到旧库上。然后等从库追平主库的一笔事务，确认position一致了，再把读写流量全部切到新库。这里有个细节，切流量之前，一定要先验证新库上的数据完整性。我会随机抽几个业务表，对比行数，再查几条最近的记录，确认时间戳和内容都跟旧库一致。另外，别忘了检查视图、函数、触发器这些东西，它们经常被忽略，但一旦丢了，应用跑起来就会报错。
切完之后，别急着撤旧库。我给自己定了个规矩，新库稳定运行满72小时，才把旧库的只读权限关掉，再过一周才真正销毁数据文件。这期间，我会写个小脚本，每小时跑一次对比，把新旧库的核心表哈希值做比对，确保没有差异。一旦发现不一致，立刻回滚到旧库，同时保留现场日志，方便排查原因。这个回滚预案，必须在迁移前就写好，包括怎么恢复写操作、怎么切换连接串、怎么通知运维和产品团队，每一步都要有明确的负责人和操作指令。别嫌麻烦，真出事的时候，这页纸比什么都值钱。
还有一件事，很多人会忽略，就是迁移过程中的监控和日志。我这次专门在Prometheus里加了一组新的告警规则，针对新库的连接数、慢查询、主从延迟、磁盘IO这几个指标，阈值设得比平时更敏感。同时，把应用端的日志级别临时调到DEBUG，这样一旦有异常，能立刻看到详细的错误堆栈。迁移结束后的头两个小时，我基本是盯着Grafana的面板，每隔十五分钟手动检查一次关键业务接口的响应时间和错误率。这不是不信任自动化，而是数据库迁移这事儿，机器能帮你省掉90%的重复劳动，但剩下的10%判断力，还得靠人。
说说人的因素。再完美的技术方案，如果团队里没人懂全流程，执行的时候照样会翻车。我这次特意拉着DBA、后端开发、运维三个人一起过了两遍演练，第一遍是纸上谈兵，把每个步骤的时间点、负责人、输出物都写清楚；第二遍是在测试环境里真刀真枪地跑了一遍，从备份到切换再到回滚，全程计时。结果还真发现了一个问题：测试环境里有个定时任务没停掉，导致切换后还在往旧库写数据。这种坑，只有演练才能踩出来。所以我的建议是，别心疼那半天时间，演练的价值远远大于你省下的那点工时。
数据库迁移这事儿，本质上是一场跟不确定性的博弈。你永远没法保证零风险，但可以通过充分的准备、细致的验证和果断的执行，把风险压到最低。这次迁移结束后，我在复盘文档里写了这么一句话：平稳过渡不是运气，是每一步都算数的结果。旧库下线那天，我看着控制台上的连接数从几百降到零，然后点了销毁按钮，屏幕上弹出一行提示：实例已删除。那一刻，我知道，这事儿算是彻底翻篇了。下次再有人问我数据库迁移怎么做到零事故，我会告诉他，先把每个细节都当成事故来对待。
