> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2025-nian/w46-shu-ju-ku-qian-yi-case-study.md).

# W46-数据库迁移Case Study

看到一篇数据库迁移的经验总结——[How We Migrated 1 Billion Records from DB1 to DB2 Without Downtime](https://medium.com/@himanshusingour7/how-we-migrated-db-1-to-db-2-1-billion-records-without-downtime-c034ce85d889)，是对一个 10 亿条金融数据库集群做零停机迁移的复盘。

和我们技术风险防控的核心思路有很多共鸣。渐进的风险控制，每一步都可以独立验证和回滚。可观测性优先，从数据库内部的 WAL 日志、缓存命中率，到业务层的订单量和收入流量，全程监控让团队能及时发现异常。我还发现数据库或者后端服务迁移，有一个很巧妙的招数，Shadow Reads。

数据迁移本质上是一个复杂的系统设计问题。作者介绍了五点重要的设计。

第一，通过分片、并行处理和禁用索引对“冷数据”进行批量迁移。

第二，引入双写机制并结合 Kafka 重试队列，确保旧库与新库之间的实时流量同步，同时保持幂等性。

第三，用Shadow Reads做在线验证。用户请求仍然从旧库读取，但每个查询会在后台悄悄对新库执行一遍，比对结果差异。这个过程持续数周，他们发现了很多测试环境永远抓不到的问题。比如时区处理差异、NULL 值的默认行为、字符排序规则不同。我后来想到去年收银台后端架构迁移好像用的就是类似招数，但前端很难复刻。

第四，在低流量时段进行谨慎切换，通过缓存预热、回滚方案和密切监控确保平滑过渡。

最后，作者强调在整个迁移过程中强可观测性的重要作用。

前端很难用上Shadow Reads的思路，因为前端每个用户访问的版本是独占的，也就是说访问了新版本就无法访问老版本。数据库的Shadow Reads是“隐形对比结果集”，前端的正确性远比数据一致复杂得多。涉及交互行为、性能体验、可访问性一致性、设备差异下的兼容，这些都缺乏低成本的可验证手段。流量灰度、用户行为数据分析、业务指标监控、人工走查，这些还是最有效的手段。