> 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-hant/2025/w46-database-migration-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是“隱形對比結果集”，前端的正確性遠比數據一致複雜得多。涉及交互行為、性能體驗、可訪問性一致性、設備差異下的兼容，這些都缺乏低成本的可驗證手段。流量灰度、用戶行為數據分析、業務指標監控、人工走查，這些還是最有效的手段。