這家銀行把10億條數據搬家，靠一個Excel公式預判了系統崩潰

遷移10億行金融數據，零丟失容忍，窗口期以小時計——這不是技術問題，是賭命問題。

AWS數據庫遷移服務（DMS）的官方文檔有312頁，但沒告訴你的是：當CDC（變更數據捕獲）延遲在切窗口前5分鐘突然飆升，你手里沒有預案，整個項目就得向董事會解釋為什么下個月才能再試。

網絡層：一個NAT地址搞癱了72小時

雙活數據中心，Site-to-Site VPN隧道（IPSec/IKEv2協議）接入AWS Transit Gateway。聽起來標準，直到源端網絡團隊給了他們內部的LAN網段：192.x.x.x。

AWS實際看到的是NAT轉換后的地址——完全不同的網段。

路由表、安全組、網絡ACL、VPN第二階段代理ID選擇器，全部配錯。數百萬次連接超時，72小時排查，最后發現是源端團隊自己也沒搞清出口IP。現在我的標準話術變成："AWS看到的到底是什么地址？"——在碰任何配置之前必須問這句。

AWS Reachability Analyzer（可達性分析器）成了強制門禁。一次遷移前它抓到一個缺失的路由表項，那項缺失會讓DMS任務在窗口期中途死掉。現在這是預遷移 checklist 的第一條。

Schema轉換：把SCT關進VPC里

AWS Schema Conversion Tool（SCT，模式轉換工具）跑在Windows EC2實例上，直接走VPC內網連Aurora，走VPN隧道連SQL Server。本地筆記本跑SCT？延遲抖動會讓大表評估超時，然后你對著一個卡住的進度條猜測是網絡還是工具bug。

憑證存在AWS Secrets Manager，IAM角色調用——配置文件里永不出現明文密碼。SOC 2 Type II審計要查這個，不是"最佳實踐"是"及格線"。

兩個轉換陷阱反復出現：SQL Server的`datetime2`精度到100納秒，Aurora PostgreSQL的`timestamp`只到微秒——批量插入時時間戳對不上，下游ETL直接斷鏈。還有計算列（computed columns），Aurora不認，必須提前物化成真實列。SCT會標黃警告，但黃得太容易被忽略。

CDC延遲預測：用Holt-Winters算法給DMS算命

DMS的CDC延遲指標每60秒吐一個數。官方做法是設個閾值告警，比如延遲>300秒就發郵件。問題是：郵件發出來的時候，你已經輸了。

我搭了個叫DMS-PredictLagNet的框架——名字唬人，核心就三層：

第一層，DMS實例物理隔離。每個遷移流獨占一個DMS復制實例，磁盤IOPS和網絡帶寬不共享。AWS文檔說"可以"共享，沒說"應該"共享。生產環境選"應該"。

第二層，Holt-Winters三重指數平滑。拿過去4小時的CDC延遲序列，分解出趨勢項、季節項（業務高峰周期）、隨機項。預測未來15分鐘的延遲軌跡。

第三層，自動擴縮容。預測值超過切窗口安全閾值時，自動觸發DMS實例升配；預測回落時，自動降配省成本。

實際跑下來的數據：預測準確率87%，提前12-18分鐘發出擴容信號。一次切窗口前23分鐘，系統預測延遲將在窗口開啟時達到47秒——高于我們設定的30秒安全線。自動擴容觸發，實際切窗口時延遲壓到19秒。

沒有這套系統，那次遷移得推遲到下個月。

生產血的教訓：三個必須寫進checklist的坑

LOB（大對象）列是隱形殺手。一張表有`varbinary(max)`存PDF掃描件，DMS默認全量加載時把整列拉進內存。復制實例16GB內存，這張表 alone 吃光，OOM崩潰。解法：對LOB表啟用"有限LOB模式"，分段傳輸，慢但穩。

身份列（Identity columns）在Aurora里需要`GENERATED ALWAYS AS IDENTITY`，但DMS全量加載時會把源端的自增值原樣插入，導致序列當前值落后于實際數據。切流后新插入行報主鍵沖突。必須全量完成后手動重置序列：`SELECT setval('seq_name', (SELECT MAX(id) FROM table));`

事務邊界是最陰險的。DMS CDC按事務提交順序復制，一個長事務（比如批量更新500萬行）在源端是"一個操作"，在CDC端是"500萬次變更排隊"。我們監控到一次長達23分鐘的長事務，直接把CDC延遲頂到8分鐘。現在源端DBA有硬性規定：遷移期間禁止超過10萬行的單事務操作。

合規不是填表：審計日志的復仇

SOC 2和PCI DSS要求"遷移全程可追溯"。我們做了三件事：

CloudTrail開全量，DMS API調用全記錄。S3存原始數據文件，啟用對象鎖定（Object Lock），保留期7年——監管要求，不是技術選擇。每次測試遷移和正式遷移，DMS任務配置JSON版本化存Git，變更 diff 自動關聯Jira工單號。

審計員真正問的是："你怎么證明沒有數據在遷移過程中被篡改？"我們的答案：行級校驗和。全量完成后，源端和目標端按主鍵分區并行計算MD5校驗和，比對報告隨遷移文檔一起歸檔。

一次審計中，校驗和比對發現3行數據不一致——最后查明是源端在全量導出后、CDC啟動前被業務系統更新，屬于預期內的時間窗口差異。但如果沒有這步，就是說不清的疑點。

這套架構跑了6個信用合作社環境，最大的單庫4.2億行，切窗口平均用時94分鐘。最短的一次67分鐘，最長的一次因為CDC延遲預測提前告警，主動推遲到下個窗口——零事故。

DMS-PredictLagNet的代碼我沒開源，核心邏輯就幾十行Python調AWS SDK。真正值錢的是那套"問AWS看到什么地址"的檢查清單，和"長事務=遷移殺手"的運維紀律。

下一個要解決的問題是：當源端變成Oracle RAC，Holt-Winters的季節項參數該怎么調——Oracle的歸檔日志切換頻率和SQL Server完全不同，預測模型的周期項得重寫。