Question

在将我的数据脱机复制到另一台服务器后神秘地发现，所有服务器上都缺少bomgar.1（数据文件）。我在此数据库的网格文件存储中有大约850GB的数据。由于缺少文件，所有修复工具都失败了。我试图复制一个＆＃34;假的＆＃34;来自另一台服务器的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中做很多事情。我对保留任何重复数据不感兴趣。＆＃34;假＆＃34;文件只有128MB，因此丢失我的数据片段比丢失整个850GB要好得多。我们正在将这些数据移动到副本集，似乎没有服务器会显示fs.files集合，给出错误bad offset:0 accessing file: /data/grid/bomgar.0. See http://dochub.mongodb.org/core/data-recovery，但我可以查看fs.chunks和系统.indexes。

总结一下：即使缺少一部分数据，如何保存我的数据呢？

Answer 1

最终，我最终使用mongodump和mongorestore，因为他们能够忽略重复项，其中db.repairDatabase()在重复时失败。我不确定为什么我从800GB的数据转到2.2TB的数据，但我不能排除在我修理服务器时添加的数据，它只是没有任何意义为什么它如此巨大。我不能确定保留了多少数据，但似乎我添加的“假”切片来阻止错误没有插入任何奇怪的文件，似乎让修复工具很开心。幸运的是，我有足够多的硬盘空间用于修复，而不是我预期的需要。

故事的道德是服从文档而不是将生产数据放在单个实例上，除非你准备失去它！我希望他们建议使用dump / restore而不是repairDatabase，因为我浪费了很多时间。

Mongo RepairDatabase在重复时失败

1 个答案: