由資料遷移至MongoDB導致的資料不一致問題及解決方案
故事背景
企業現狀
2019年年初，我接到了一個神祕電話，電話那頭竟然準確的說出了我的暱稱：上海小胖。
我想這事情不簡單，就回了句：您好，我是小胖，請問您是？
“我就是剛剛加了你微信的 xxx 啊”
哦……他只是把我的微信暱稱報出來了……
隨著深入溝通，瞭解到對方是某央企保密單位的大資料部門技術負責人，因為目前整個集團在進行數字化轉型。在決策過程中，遇到了幾個阻力。
首先，大部分部門和科室的資料基礎還很薄弱，存在資料標準混亂、 資料質量層次不齊、各條塊之間資料孤島化嚴重等現象，阻礙了資料的共享應用。
其次，受限於資料規模和資料來源種類的豐富程度，多數企業的資料應用剛剛起步，主要集中在精準營銷，輿情感知和風險控制等有限場景，應用深度不夠，應用空間亟待開拓。
再次，由於資料的價值很難評估，企業難以對資料的成本以及其對業務的貢獻進行評估，從而難以像運營有形資產一樣管理資料資產。
而這位技術負責人本著認真、負責、專研的精神，死磕大資料領域，試圖在市面上找到一款能夠滿足他需求的產品，幫助他解決資料痛點。
經過溝通，瞭解到目前的企業資料現狀是：
- 資料散落在各部門科室，8大部門共50+科室
- 資料量非常大，高峰期每小時可產生100GB資料，每天存量資料 1TB
- 資料型別豐富，包括：
- 關係型資料庫：Oracle，MySQL，PostgreSQL，GBase，GauseDB等
- 非關係型資料庫：MongoDB
- 結構化檔案：XML，Excel，CSV，TXT
- 非結構化檔案：音訊，視訊，pdf
- 每個月都會有 5 個新專案，而每次對接新專案都需要花費 1-3個月時間在資料對接上
- 專案週期長，而大多數時間都在資料冗餘、清洗、過濾上
- 多副本資料帶來的資料維護成本也在不斷增加，影響了研發進度
考慮遷移
在堅定不移的執行數字化轉型戰略，打贏傳統資料組織轉向大資料生態的攻堅戰中，技術負責人悟出了一個道理，要打贏這場硬仗，必須得做資料整合！
要做資料整合，那不就是傳統資料倉庫和資料湖嗎？在技術負責人經過一番市場調研後發現，資料倉庫和資料湖都無法滿足他心中的未來大資料架構。
那是什麼樣的資料架構無法滿足呢？面向應用開發的共享資料
簡而言之就是，資料倉庫和資料湖無法做即時交付，目前的應用場景還是如上文提到的：應用深度不夠，應用空間亟待開拓。
經過幾番調研後，技術負責人找到一款產品Tapdata，用他的原話說就是：“這款產品的理念很先進，可以說和我的想法不謀而合。”
擴充套件開來說就是：
- 通過資料同步完成資料匯聚、採集工作
- 通過資料釋出對外提供資料服務
- 通過資料治理對資料資產進行有效管理
而最重要的是資料是可被重複使用，可實時交付的。
解決方案
架構
Tapdata 的資料同步工具，只需要簡單的拖拉拽，就可以完成多源資料庫的同步。同時依賴於靈活的 js 指令碼能力，對複雜的 ETL 場景也可以非常輕鬆搞定。
那這裡就上一個當時給技術負責人就他們企業現狀做的架構圖，因為本篇文章是在討論資料遷移，所以我就給出資料同步的架構圖。
整個架構採取 mongodb 分片叢集作為底層儲存，使用資料同步工具將多源資料實時抽到 mongodb 中，在抽取過程中完成資料清洗、過濾。
技術實現
在使用資料同步工具做資料遷移的時候，需要和使用者溝通具體場景，比如：
- 本次目標是一次性資料匯入，還是需要之後保持增量同步
- 資料遷移中有沒有複雜的ETL場景
- 對同步延時要求
- 同步的資料量預估，高峰預估
在明確目標和需求後，我們採取了多節點分散式採集的方式來滿足應用高峰時產生的資料量，根據當時預估高峰每小時 100GB，一天存量 500GB 計算。
通過資料工具將不同的資料來源，通過任務編排的方式進行組合，完成資料清理工作。
使用者本次資料同步要求更多是在資料同步效能及資料量上，對資料的ETL沒有過多的要求，都是一些簡單的欄位重新命名，欄位型別轉換
所以通過資料同步工具只需要 1 分鐘即可完成從源端資料庫到目標端 mongodb 的同步工作。
建立資料來源
編排任務
和實施前對比
目前上線的資料來源有 Oracle、MongoDB、MySQL、PostgreSQL、GBase。資料庫叢集數量達到10+套，同時支撐3條完整業務線運作，併發高峰達到 18w/秒。
有效解決了當時阻礙技術負責人執行的最大障礙：大資料量的資料同步工作，及落地後的資料管理。
新增業務時，使用者技術人員只需要做簡單的拖動就可以完成。減少了技術人員的開發工作，幫助技術人員將更多的時間聚焦在核心業務上。極大縮短了專案上線週期。
孤兒文件
現象
在運行了一段時間後，在一次新應用接入後，發現接入的資料有重複，通過TD的資料比對工具發現源端 mongo 和目標端 mongodb 在相同表的資料量上確實存在差異。
這個事情對於資料同步工具來說是非常致命的，資料同步最核心的能力就是要保障資料的一致性，而資料同步工具的資料冪等性也是經過中國軟體評測中心的測試認證的。
對於該現象的發生，我們團隊非常重視，如果真是同步工具導致的資料不一致性，那就是致命bug。需要回歸所有功能。
排查
隨機便在第一時間聯絡上使用者技術，並開展了一系列的排查工作。
確認資料庫型別
排查第一步就是確認源端和目標端的資料庫型別和作業系統配置。
本次出現數據重複的任務涉及到的資料庫情況是：
- 源端資料庫
- mongo 3.2
- 單例項副本集
- 64c 256GB SAS硬碟
- 萬兆光纖內網
- 目標端資料庫
- mongo 4.0
- 6分片叢集
- 64c 256GB SAS硬碟
- 萬兆光纖內網
找出重複資料
既然有重複資料，那我們就要先找出這些資料來。
源端資料庫是 mongo，目標端也是 mongo，這就比較好辦了，寫一套 js 指令碼即可。這裡會有一個坑，後面會說到，就是分片叢集需要去每個節點上查，而不要在 mongos 上查。
指令碼很簡單，因為資料同步工具在同步的時候是會根據業務主鍵同步的，所以我就可以在目標端集合中，遍歷每條資料，然後拿著業務主鍵去源端資料庫查詢，比對所有值。
這個過程會很慢，但只能等。
當然要注意的是，由於源端資料庫是單節點，所以理論上應該同步一份資料出來作比對會好些，但是由於該業務還沒上線，所以影響不大。而目標端資料的話是可以通過查詢從節點資料進行比對的。
比對結果就是二十幾張表一共 1kw 的資料，有十幾萬重複。看起來這個重複的資料量還不少。
這裡我定義的重複資料就是相同的業務主鍵應該是資料唯一的，但在目標端卻查到不止一條。
檢查資料同步工具日誌
現在有了重複資料，就可以去資料同步工具日誌裡查詢了。
在同步過程中是否有出現數據重複，或者 ERROR，如果發現有 duplicate key 字樣，那就可以順著這條記錄往下排查。
但很遺憾，在日誌中並沒有發現類似字眼
檢查 mongodb 日誌
資料同步工具日誌無果，轉戰 mongodb 日誌，通過檢視 mongodb 日誌，發現有大量的recvChunk 和 moveChunk 日誌
看到這個，我一下子就不困了呀。
我簡單給大家說下這段日誌在幹嘛。因為目標端 mongodb 是分片叢集，分片中有一個很重要的概念叫塊移動。分片叢集是以資料塊（chunk）為最小單位進行儲存的，預設一個塊可以儲存64MB大小資料。
那這和本次的資料不一致又有什麼關係呢？抖精神的地方來了，mongodb 對於均衡分片的處理方式是：先將 shard 1 節點的 chunk 拷貝到 shard 2 節點去，當 chunk 完全拷貝完成後，在將 shard 1 節點的 chunk 刪了。
那麼在這個轉移的過程中，大家就可以想到，有好幾個環節都會發生意外，從而導致塊遷移失敗。
排查到這裡，就有必要和使用者確認當天的操作流程了。
果不其然，當天其實發生過伺服器斷網，而這個斷網就是在業務剛剛接入的10分鐘後。讓我們來還原案發現場。
使用者開啟同步任務，資料開始按預期向目標端資料庫按規則同步。
同步10分鐘後，機房斷網，此時資料同步任務處於重試階段，mongodb 叢集全部斷開網路。
斷開網路期間，mongodb 在進行的塊遷移被迫終止。
一段時間後，網路恢復，資料同步自動重試機制保證使用者無需人工干預，繼續開始同步任務。
mongodb 繼續開始塊遷移。
發現沒有，在第五步的時候，mongodb 的塊遷移並沒有去幹預之前塊遷移失敗的結果，其實這麼說不嚴謹，mongodb config server 上記錄的元資料還是認為這個塊在 shard1 上，而已經從 shard 1 節點 copy 到 shard 2 節點的資料並沒有被刪除。因此最終 count 出來的資料就會有大於原來資料總數的情況。
解決
那為了解決這個問題，其實官方是有預見的。給出了官方的解決方案。
這裡我幫大家總結好了，執行下面這段指令碼在各個分片節點上。
var nextKey = { };
vard result;
while ( nextKey != null ) {
result = db.adminCommand( { cleanupOrphaned: "<COLLECTION>", startingFromKey: nextKey } );
if (result.ok != 1)
print("Unable to complete at this time: failure or timeout.")
printjson(result);
nextKey = result.stoppedAtKey;
}這段指令碼就在做一件事情：找出不屬於 config 節點記錄的資料標識範圍，並將其刪除。
總結
那通過這件事情，檢視官方文件，我們總結了幾點：
在使用資料同步工具遷移資料到 mongodb 分片叢集的時候，需要作如下動作
- 停止平衡器：如何停止平衡器
- 使用cleanOrphan命令：如何清理孤兒文件
- 面對資料不一致性，排查思路可以從資料庫、同步邏輯出發
- 專業的事交給專業的人做。