Mongo RepairDatabase 重复失败

Question

在将我的数据离线复制到另一台服务器后，所有服务器上都丢失了bomgar.1（一个数据文件）。我在这个数据库的网格文件中存储了大约 850GB 的数据。由于缺少文件，所有修复工具都失败了。我试图从另一台服务器（相同的数据库名称，相同的文件大小）复制“假”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 中做的不多。我对保留任何重复数据不感兴趣。 “假”文件只有 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。

总结一下：即使丢失了一部分数据，我如何保存数据？

Answer 1

最终，我最终使用了mongodump 和mongorestore，因为它们能够忽略重复项，而db.repairDatabase() 在遇到重复项时会失败。我不太确定为什么我的数据从 800GB 变成了 2.2TB，但我不能排除在维修服务器时添加数据的可能性，它为什么会这样是没有任何意义的巨大的。我无法确定保留了多少数据，但我添加的用于阻止错误的“假”切片似乎没有插入任何奇怪的文档，并且似乎让修复工具感到高兴。幸运的是，我的可用硬盘空间比我预期的要多得多。

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