首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >Mongo RepairDatabase重复失败

Mongo RepairDatabase重复失败
EN

Stack Overflow用户
提问于 2015-07-11 19:41:29
回答 1查看 448关注 0票数 1

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

代码语言:javascript
复制
> 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
}

我在蒙戈空壳里做的不多。我不想保留任何重复的数据。“假”文件只有128 my,因此丢失该数据片段比丢失整个850 my要好得多。我们正在将这些数据移动到一个复制集中,似乎没有一个服务器会显示fs.files集合,从而给出错误bad offset:0 accessing file: /data/grid/bomgar.0. See http://dochub.mongodb.org/core/data-recovery,但是我可以查看fs.chunks和system.indexes。

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

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2015-07-18 04:44:20

最终,我使用了mongodumpmongorestore,因为他们能够忽略重复,而db.repairDatabase()在遇到重复时失败了。我不太清楚为什么我会从800 it的数据增加到2.2TB的数据,但我不能排除在服务器准备进行修复时添加数据的可能性,它只是没有任何意义,因为它变得如此庞大。我无法确定保留了多少数据,但我添加的阻止错误的“假”切片似乎没有插入任何奇怪的文档,似乎使修复工具感到高兴。幸运的是,我有比我预期的更多的硬盘空间可用于修复。

故事的寓意是服从文档,而不是把生产数据放在一个实例上,除非你准备丢了它!我确实希望他们建议使用转储/恢复,而不是repairDatabase,因为我在这方面浪费了很多时间。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/31361095

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档