資料庫不停機搬遷的難題：為什麼對帳比追延遲更讓工程師睡不著

一次線上遷移進入割接前夜，最讓團隊心裡沒底的，通常同步延遲還剩多少，而是另一個問題：目標庫裡的資料，真的和來源庫對得上嗎？

來源系統沒有停。新訂單還在寫入，支付狀態持續更新，售後流程又不斷修改舊資料。如果只在全量搬遷結束時比一次行數，那份結果幾分鐘後就會過期；如果把所有校驗都留到停寫窗口，割接當晚就只能一邊等、一邊賭。金倉的異構資料同步軟體 Kingbase FlySync（KFS）採取的做法，是把同步、校驗和差異修復放在同一條遷移鏈路上，讓資料在持續變化時也能比對，多數問題可以在正式切換之前處理完。

這篇文章從運作機制出發，把這套流程拆開講清楚。對任何經手過系統搬遷的團隊來說，重點從來不是工具名稱，而是「不停機搬遷時，資料一致性到底怎麼驗證」這個通用問題。

全量搬完後，增量要從同一個位點接上

線上遷移有兩條同時推進的線。一條處理存量資料，把已經存在的表和記錄搬到目標資料庫 KingbaseES；另一條從確定的日誌位點開始追增量變化，持續處理搬遷期間產生的 INSERT、UPDATE 和 DELETE。

這個位點必須與全量基線對齊。接早了，目標端可能重放已經包含在全量資料裡的變更；接晚了，中間一段交易就會落下。以 SQL Server 的線上遷移場景為例，KFS 會從全量備份對應的 eventId 開始增量解析，目的就是把全量基線和後續日誌接在同一個位置上。

用一個日常比喻：這像是在錄影節目中途換攝影機。你不能隨便從某一幀接著拍，必須記住舊機器錄到第幾分第幾秒，新機器從那個時間點之後接手，觀眾才不會看到重播或漏掉畫面。全量基線生成時間、增量開始解析的日誌位點、目標端已套用的最新序號，這三個時間點就是那捲帶子上的刻度。

實務上需要保留並持續追蹤這三類資訊。延遲看板反映的是追平速度，位點說明的則是從哪裡開始、已經處理到哪裡。兩組資訊要一起看，才能確認增量鏈路是完整的。這與我們先前討論過的高並發下餘額扣減為什麼會出錯是同一類問題：系統真正的風險往往藏在時序與狀態對齊的細節裡，而非單一環節的正確性。

業務還在寫，校驗不能只數行數

來源庫仍在承載業務時，兩端各執行一次 COUNT(*) 很容易得到不同結果。第一條查詢和第二條查詢本來就不在同一時刻執行，這種差異未必代表資料遺失。把時鐘的差距誤判成資料的差距，是遷移校驗最常見的冤案。

KFS 的資料比對分為精簡模式和詳細模式。精簡模式用於快速比對兩端的資料量；詳細模式可繼續定位表內差異，並支援差異校驗和無縫校驗。其中無縫校驗就是為持續有業務寫入的場景準備的，目的是避免把正常的並發變更誤判為同步異常。

比較務實的操作順序是：先用精簡模式掃全庫，快速找出數量不一致的表，再對訂單、支付、退款等核心表啟用詳細比對。這樣不必一開始就對全庫所有表做最細粒度的校驗，也不會把一張小型代碼表和交易主表放在同一優先級上。校驗資源的分配，本質上是一次風險排序。

工具找差異，SQL 負責核對業務口徑

行數對上之後，核心表還要看金額、狀態和時間範圍。一張訂單表即使兩端都是一百萬行，也可能存在一條訂單缺失、另一條重複的情況。工具給出表級和行級差異，業務驗收則要用固定口徑再核一遍。

例如按自然日核對訂單時，與其對時間欄做字串轉換，不如直接使用左閉右開的時間區間：created_at 大於等於當日起點、小於隔日零點。這個寫法避開了字串比對的邊界陷阱，也讓兩端查詢的窗口定義完全一致。

支付表則要單獨核對成功金額和訂單數，以 pay_status 等於成功、paid_at 落在同一時間窗口為條件，統計去重後的訂單數、交易筆數、金額合計與最新支付時間。這一步能及時發現「訂單狀態已經更新、支付流水卻還沒到達目標端」這類鏈路落後的具體證據。

這兩組查詢應在兩端使用相同的時間窗口與狀態口徑執行；異構來源庫的時間字面量語法，則按原資料庫的慣例調整。總行數、分組行數、金額合計和最新業務時間同時對上，比單獨記錄一個 COUNT(*) 更能說明問題。

匯總一致之後，還要排除互相抵銷的假象

匯總數字對上，校驗還沒結束。一張表少了一條記錄、又多了一條記錄，總數剛好抵銷，金額也可能碰巧對上。這就是為什麼表級比對之後，還需要行級或鍵值級的核對，確認每一筆關鍵交易的鍵值在兩端都存在且一致。

這也解釋了為什麼 KFS 要把差異修復放進同一條鏈路。發現差異後，若修復動作與同步流程脫節，修復期間新產生的增量可能再次造成不一致。同步、校驗、修復三者共用位點資訊，差異處理才能在一個確定的快照基礎上進行，而不是修完又追、追完又修的循環。

對照遷移現場的實際節奏，這樣的設計把原本集中在割接當晚的壓力，分散到遷移期間的每一天。團隊在停寫窗口到來之前，已經有多輪校驗結果可以參考，切換當晚要做的是最後確認，而不是第一次全面對帳。

一般團隊能帶走的三件事

第一，位點比延遲重要。延遲數字好看只代表追得快，位點連續才代表沒漏。監看遷移時，把全量基線時間、增量起始位點、已套用序號三個數字放在同一塊看板上。

第二，校驗分層做。先用粗粒度掃全庫找可疑的表，再對金流相關的核心表做細粒度比對。校驗資源有限時，優先級應該跟著業務風險走，而非表面上行數最多的表。

第三，工具結果與業務口徑要分開驗。同步工具回答的是「兩端資料是否一致」，業務驗收回答的是「這些資料按公司的對帳規則是否算對」。兩者用的方法、跑的時機、負責的人都可能不同，缺一不可。

資料庫遷移最終交付的其實是一份信心：切換那一刻，沒有人需要猜。而信心無法在割接當晚憑空生出來，它只能在遷移的每一天裡，用一輪一輪的位點核對與差異修復慢慢累積。無論團隊用的是 KFS 還是其他工具，這個原則都成立。