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重复失败

回答

相关问题