由資料遷移至MongoDB導緻的資料不一緻問題及解決方案

本文是“我和MongoDB的故事”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分片叢集

找出重複資料

既然有重複資料，那我們就要先找出這些資料來。

源端資料庫是 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分鐘後。讓我們來還原案發現場。

1. 使用者開啟同步任務，資料開始按預期向目标端資料庫按規則同步。
2. 同步10分鐘後，機房斷網，此時資料同步任務處于重試階段，mongodb 叢集全部斷開網絡。
3. 斷開網絡期間，mongodb 在進行的塊遷移被迫終止。
4. 一段時間後，網絡恢複，資料同步自動重試機制保證使用者無需人工幹預，繼續開始同步任務。
5. mongodb 繼續開始塊遷移。

發現沒有，在第五步的時候，mongodb 的塊遷移并沒有去幹預之前塊遷移失敗的結果，其實這麼說不嚴謹，mongodb config server 上記錄的中繼資料還是認為這個塊在 shard1 上，而已經從 shard 1 節點 copy 到 shard 2 節點的資料并沒有被删除。是以最終 count 出來的資料就會有大于原來資料總數的情況。

解決

那為了解決這個問題，其實官方是有預見的。給出了官方的解決方案。

這裡我幫大家總結好了，執行下面這段腳本在各個分片節點上。

var nextKey = { }; vard result;

while ( nextKey != null ) {

result = db.adminCommand( { cleanupOrphaned: "", startingFromKey: nextKey } );

if (result.ok != 1)

print("Unable to complete at this time: failure or timeout.")
           

printjson(result);

nextKey = result.stoppedAtKey;

}

這段腳本就在做一件事情：找出不屬于 config 節點記錄的資料辨別範圍，并将其删除。

總結

那通過這件事情，檢視官方文檔，我們總結了幾點：

1. 在使用資料同步工具遷移資料到 mongodb 分片叢集的時候，需要作如下動作

a.停止平衡器：如何停止平衡器

b.使用cleanOrphan指令：如何清理孤兒文檔

1. 面對資料不一緻性，排查思路可以從資料庫、同步邏輯出發
2. 專業的事交給專業的人做。

作者：楊慶麟

Tapdata Solution Architect，第一批MongoDB認證獲得者；公衆号「Python專欄」作者。