证明一致，而不是相信一致
上一篇的双写把新库追到了「延迟趋近于零」，但迁移工程到这里只能算半程——双写成功不代表数据一致：同步程序漏一条变更、转换逻辑错一个字段、双写重试丢一笔，都会造成两边数据的静默分叉。这种分叉平时看不出来，切流之后变成线上资损。所以校验阶段的目标只有一句话：用证据证明两边一致，而不是相信它一致。
三道校验关
第一道：行数核对——最粗也最快，按表、按天、按分片分别 count 对比，五分钟找出大方向的窟窿；第二道：分块 checksum——按主键区间把数据切块，两边各算每块的字段拼接哈希（或直接用 MySQL 的 CRC32），块哈希不等就再二分缩小范围，最终定位到不一致的行。全程用主键区间分批，不锁表、可断点重跑；第三道：抽样比对——随机抽十万行做全字段逐项比对，checksum 查不出的语义差异（类型转换、精度、默认值）靠它兜底。三道关的产出是一份差异清单，差异要逐条归因：双写窗口内的正常延迟可忽略，转换 bug 要修程序，同步丢的要补数据——差异清零才准进入切流。
灰度切流：先读后写，逐步放大
切流的精髓是每次只切一小步，每一步都观察、可回退。标准节奏四步：影子读——线上仍读老库，但同一请求并行读新库比对结果，只记日志不返回，跑一周统计差异率；白名单读——内部账号与灰度用户的读切到新库，坐监控看错误率与耗时；全量读——读流量全切新库，写仍双写、以老库为准；切写——写入口切到新库，老库降级为反向同步的从属（binlog 反向追，保持老库仍可用）。每一步之间留观察期，指标异常立即回退上一步。切流开关要做成配置中心热生效，秒级切换、秒级回退——回滚预案不是文档里的一段话，是一个真实的开关。
回滚的门要一直开着
切写之后最危险的操作是急着下线老库。老库必须保留到新库经受过完整业务周期的考验——大促流量、月度对账、批量任务全都跑过一遍，反向同步把新库的变更追回老库，保持老库随时可接管。这个观察期以周为单位计，期间任何回滚都是「把开关拨回去」的事。直到某一天，团队确认不再需要保险，才依次：停反向同步、老库转只读备份、归档下线。迁移项目的里程碑不是切流成功，是老库安全下线——前者只是把风险换了个位置，后者才算真正交割完成。
迁移讲完，工程主线还剩两块：分片环境下的表结构变更（几百张物理表怎么改）与日常治理（归档、监控、倾斜）。下一篇先解一个高频刚需——在线 DDL。
评论 (0)