Mongo RepairDatabase重複失敗

將數據脫機複製到另一臺服務器後，在所有服務器上都缺少bomgar.1（數據文件），神祕莫測。我在這個數據庫的網格文件存儲中有大約850GB的數據。所有修復工具由於缺少文件而失敗。我試圖從另一臺服務器（相同的數據庫名稱，相同的文件大小）複製一個「假」bomgar.1，這使得修復工具可以轉儲出數據，但是當它們插入有效的文檔時（很多小時後），我得到了以下輸出：Mongo RepairDatabase重複失敗

> use bomgar 
switched to db bomgar 
> db.repairDatabase() 
{ 
     "ok" : 0, 
     "errmsg" : "E11000 duplicate key error index: bomgar.fs.chunks.$files_id_1_n_1 dup key: { : null, : null }", 
     "code" : 11000 
}

我在Mongo shell中並沒有做很多。我對保留任何重複數據不感興趣。「假」文件只有128MB，因此丟失我的數據片比丟失整個850GB要好得多。我們正在將這些數據轉移到副本集，並且似乎沒有一個服務器會顯示fs.files集合，提供了錯誤bad offset:0 accessing file: /data/grid/bomgar.0. See http://dochub.mongodb.org/core/data-recovery，但我可以查看fs.chunks和system.indexes。

總結：即使缺少一部分數據，我如何保存數據？

來源

2015-07-11 QuickDanger

還有一點值得注意的是：當以這種方式恢復時，我至少得到了1.5倍的被轉儲數據的大小（最後在睡眠前檢查過）。現在_tmp數據不見了，但我還沒有看到修復工具的任何地方使用更多的修復空間。 – QuickDanger

最終，我結束了使用mongodump和mongorestore，因爲他們能夠忽略重複，其中db.repairDatabase()失敗時，它重擊。我不確定爲什麼我從800GB的數據到2.2TB的數據，但我不能排除數據被添加，而我有服務器修復，它只是沒有任何意義，爲什麼它如此巨大。我無法確定保留了多少數據，但似乎我添加的用於阻止錯誤的「假」片沒有插入任何奇怪的文檔，並且似乎使修復工具開心。幸運的是，我有更多的硬盤空間可用於修復，比我預期的要多。

故事的寓意是服從文檔，不要將生產數據放在單個實例上，除非您準備丟失它！我希望他們會建議使用dump/restore而不是repairDatabase，因爲我浪費了很多時間。

來源

2015-07-18 04:44:20 QuickDanger

Mongo RepairDatabase重複失敗

回答

相關問題