由數據遷移至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分片集羣
• 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分鐘後。讓咱們來還原案發現場。

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: "<COLLECTION>", 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命令：如何清理孤兒文檔

2. 面對數據不一致性，排查思路能夠從數據庫、同步邏輯出發
3. 專業的事交給專業的人作。

做者：楊慶麟
Tapdata Solution Architect，第一批MongoDB認證得到者；公衆號「Python專欄」做者。

感謝MongoDB官方，錦木信息和Tapdata對活動的大力支持！

本文由MongoDB中文社區（mongoing.com）小芒果 （微信ID：mongoingcom）經過[OpenWrite]發佈！