Mongodb Mongo RepairDatabase在复制时失败

在将我的数据脱机复制到另一台服务器后，所有服务器上都丢失了数据文件。我在这个数据库的网格文件存储中有大约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集合，从而导致错误

错误偏移量：0访问文件：/data/grid/bomgar.0。看见http://dochub.mongodb.org/core/data-recovery

，但我可以查看fs.chunk和system.index

---

总而言之：即使缺少数据的一部分，如何保存数据？

最终，我使用了

mongodump

和

mongorestore

，因为它们能够忽略重复的数据，而

db.repairDatabase（）

在遇到重复数据时失败。我真的不知道为什么我的数据从800GB增加到了2.2TB，但我不能排除在服务器维修期间添加数据的可能性，这就是为什么它变得如此巨大的原因。我不能确定保留了多少数据，但我为阻止错误而添加的“假”切片似乎没有插入任何奇怪的文档，似乎让修复工具感到高兴。幸运的是，我有相当多的硬盘空间可供修复，比我预期的需要

---

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

同样值得注意的是：当以这种方式恢复时，我得到的数据大小至少是转储数据的1.5倍（上次我在睡觉前检查）。现在，tmp数据不见了，但我还没有看到任何地方提到修复工具使用了更多的空间进行修复。