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

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

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

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

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

有大牛能幫忙分析解釋一下嗎，分析了一周左右，實(shí)在是沒(méi)有頭緒。

回答

編輯回答

半心人

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

非正常關(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é)果不準(zhǔn)確：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ù)庫(kù)中統(tǒng)計(jì)到的數(shù)量為39804543。

因?yàn)槌绦蚝蛃hell中返回的數(shù)據(jù)應(yīng)該是一樣的，所以你可能是上述第二種可能性。要得到準(zhǔn)確的數(shù)值需要用照文檔中所述使用aggregation統(tǒng)計(jì)正確的結(jié)果。

補(bǔ)充

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

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

2018年2月3日 23:08

編輯回答