数据迁移：零停机迁移，数据同步校验。

数据迁移最怕的不是“搬得慢”，而是“搬完了不敢切”。业务在跑，用户在写，订单、库存、账户余额每分每秒都在变化，一旦停机窗口过长，损失的不只是 GMV，还有用户信任。所谓零停机迁移，并不是真的没有任何感知，而是把不可用时间压缩到秒级甚至无感，同时保证迁移前后数据一致、可回滚、可验证。

很多团队把迁移当成一次性的 ETL 任务，结果在切流当晚才发现：新库少了半小时增量，旧库还有未同步的软删除记录，自增主键冲突导致写入失败。真正可靠的迁移方案，必须同时解决三个问题：存量怎么搬、增量怎么追、一致性怎么证明。

零停机的本质：把“大爆炸”拆成可回滚的小步

零停机迁移的核心不是某个神奇工具，而是把“一次性切换”拆成“可并行的双轨运行”。典型路径是：先全量迁移存量数据，再通过 CDC 或双写追增量，接着用影子库或新库承接读流量做灰度验证，最后在短暂禁写窗口内完成最终增量对齐和切流。

这个过程中，每一步都要可回滚。切流不是“一锤子买卖”，而是一个开关：发现异常，能在分钟级切回旧库。为了做到这一点，应用层需要抽象出数据访问路由，让读写流量可以按比例、按租户、按业务线逐步迁移，而不是全局一刀切。

同步链路：双写、CDC 与兜底补偿

增量同步常见两条路：应用层双写和数据库层 CDC。双写实现简单，但侵入业务代码，容易漏写、顺序错乱，且难以处理历史数据回填。CDC 对业务透明，能捕获 insert、update、delete 甚至 DDL，但依赖 binlog 格式、位点管理和下游消费能力。

更稳妥的做法是“CDC 为主、双写为辅、对账兜底”。CDC 负责大多数增量，双写用于关键字段的实时校验或补偿，定时对账任务则负责发现并修复长期不一致。要注意，同步链路必须幂等：同一条变更重复消费不能产生副作用，否则重试机制反而会放大脏数据。

校验不是抽查，而是可证明的一致性

“抽样对比没发现问题”不能作为切流依据。数据同步校验需要分层设计：全量校验负责表级、分片级的 checksum 比对；增量校验负责按时间窗口或位点比对变更记录；业务级校验则关注金额、库存、状态机等关键不变量。

实践中，全量 checksum 对大数据量并不友好，可以按主键分片、并行计算，并排除已知的动态字段。对于金额、余额这类敏感数据，最好做逐笔核对或聚合对账，而不是只看总数。校验结果要能定位到具体行、具体字段，并自动进入修复队列。没有修复通道的校验，只是“发现问题”，不是“解决问题”。

切流与回滚：把开关握在手里

切流前要明确几个指标：增量延迟是否持续低于阈值、校验差异是否收敛、新库容量与慢查询是否达标、回滚脚本是否演练过。切流时通常先禁写旧库，等待增量追平，校验通过后切换路由，再恢复写入。禁写窗口应尽量短，最好控制在秒级到分钟级。

回滚方案要提前演练，不能只写在文档里。回滚不仅是切回旧库，还要处理新库期间产生的增量如何反向同步，否则回滚本身就会造成二次数据丢失。

那些容易翻车的细节

自增主键、时区、字符集、浮点精度、软删除、逻辑外键、触发器、DDL 变更，都是迁移中的老演员。比如旧库用 `datetime` 存本地时间，新库用 `timestamp` 存 UTC，迁移后报表就会偏移；旧库自增 ID 在新库被重新分配，关联关系可能错乱。迁移前做一轮字段级映射评审，比事后修数据便宜得多。

零停机迁移是一场关于确定性的工程。它考验的不是工具多先进，而是团队是否把同步、校验、切流、回滚组成闭环。存量搬得完，增量追得上，差异说得清，异常回得去，才敢说这次迁移真正做到了零停机。数据迁移的终点不是“新库上线”，而是“业务无感，数据可信”。