Mongo 修复数据库复制失败

Mongo RepairDatabase Failed on Duplicate

奇怪的是,在将我的数据离线复制到另一台服务器后,bomgar.1(数据文件)在所有服务器上都丢失了。我在这个数据库的网格文件存储中有大约 850GB 的数据。由于文件丢失,所有修复工具都失败了。我试图从另一台服务器(相同的数据库名称,相同的文件大小)复制 "fake" bomgar.1,这允许修复工具转储数据,但是当它们插入有效文档时(很多很多小时后),我得到以下输出:

> 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 中做的不多。我对保留任何重复数据不感兴趣。 "fake" 文件只有 128MB,所以丢失那部分数据比丢失整个 850GB 好得多。我们正在将此数据移动到副本集,似乎 none 的服务器将显示 fs.files 集合,给出错误 bad offset:0 accessing file: /data/grid/bomgar.0. See http://dochub.mongodb.org/core/data-recovery,但我可以查看 fs.chunks 和 system.indexes.

总结一下:即使丢失了一部分数据,我该如何保存?

最终,我最终使用了 mongodumpmongorestore,因为它们能够忽略重复项,而 db.repairDatabase() 在遇到重复项时失败了。我不太确定为什么我的数据从 800GB 增加到 2.2TB,但我不能排除在服务器进行维修时添加数据的可能性,只是没有任何意义为什么会这样巨大的。我不能确定保留了多少数据,但似乎我添加的 "fake" 切片来阻止错误并没有插入任何奇怪的文档,并且似乎让修复工具很高兴。幸运的是,我有比预期需要更多的硬盘 space 用于维修。

故事的寓意是遵守文档,不要将生产数据放在单个实例上,除非您准备好丢失它!我真希望他们建议使用 dump/restore 而不是 repairDatabase 因为我在这上面浪费了很多时间。