鍍金池/ 問答/數(shù)據(jù)庫/ 疑似MongoDB數(shù)據(jù)丟失問題

疑似MongoDB數(shù)據(jù)丟失問題

使用MongoDB進行數(shù)據(jù)插入，發(fā)現(xiàn)存在數(shù)據(jù)丟失問題。

集群環(huán)境：五臺windows server2008服務(wù)器，配備五個shard，模式為一主一從一仲裁。

場景描述：現(xiàn)有約4000w數(shù)據(jù)，大小為62G（圖片數(shù)據(jù)），使用MongDB C# Driver提供的IMongoCollection接口的insertMany方法批量插入，每次大概100條，程序的寫入模式已經(jīng)配置為WriteConcern.Acknowledge，并且開啟了journal，InsertMany處也是用try捕捉了異常，最終執(zhí)行結(jié)果是未捕捉到異常。程序執(zhí)行完成后，發(fā)現(xiàn)缺少部分數(shù)據(jù)。

程序解析到的數(shù)據(jù)量為39821308條，而mongoDB數(shù)據(jù)庫中統(tǒng)計到的數(shù)量為39804543。

有大牛能幫忙分析解釋一下嗎，分析了一周左右，實在是沒有頭緒。

回答
編輯回答
半心人

因為做MongoDB相關(guān)服務(wù)，隔三差五就會被疑似丟失一回，不過目前為止都沒有哪一個是真的丟失的。
如果有十足的把握沒有代碼上的問題，大部分人遇到的情況可能有以下幾種：

非正常關(guān)閉后count結(jié)果不正確：Accuracy after Unexpected Shutdown;

After an unclean shutdown of a mongod using the Wired Tiger storage engine, count statistics reported by count may be inaccurate.

在Sharding環(huán)境中count結(jié)果不準確：Behavior

On a sharded cluster, count can result in an inaccurate count if orphaned documents exist or if a chunk migration is in progress.

你上面提到:

程序解析到的數(shù)據(jù)量為39821308條，而mongoDB數(shù)據(jù)庫中統(tǒng)計到的數(shù)量為39804543。

因為程序和shell中返回的數(shù)據(jù)應(yīng)該是一樣的，所以你可能是上述第二種可能性。要得到準確的數(shù)值需要用照文檔中所述使用aggregation統(tǒng)計正確的結(jié)果。

補充

基于你提到的情況，另外一些可能導(dǎo)致數(shù)據(jù)缺失的情況：

  1. 是否在大批量插入數(shù)據(jù)時壓力超過極限導(dǎo)致結(jié)點發(fā)生過主從切換？可以觀察日志中是否有出現(xiàn)過PRIMARY, SECONDARY等關(guān)鍵字來確定是否發(fā)生過切換。
  2. 默認情況下寫入操作使用w=1，是否有修改過默認行為？
  3. 還有一種很少見但是確實在實際中遇到過的情況，是否插入的數(shù)據(jù)又被刪除了？可以在local.oplog.rs中查找是否有出現(xiàn)過缺少的文檔的_id來確定這一點。
2018年2月3日 23:08
編輯回答
遺莣

檢查下數(shù)據(jù)是否被覆蓋寫入了。

2017年7月22日 07:35