【问题标题】:MongoDB repair command failedMongoDB 修复命令失败
【发布时间】:2012-12-03 09:11:14
【问题描述】:

以前我的磁盘空间不足,mongodb 停止工作。然后我增加了磁盘大小,但 mongodb 没有开始工作。

虽然我启用了日记功能,但我执行了以下命令
sudo -u mongodb mongod --dbpath /var/lib/mongodb/ --repair

但是这个修复命令出现异常,停止修复然后退出。

    Fri Nov 30 13:29:36 [initandlisten] build index bd_production.news { _id: 1 }

    Fri Nov 30 13:29:36 [initandlisten]      fastBuildIndex dupsToDrop:0

    Fri Nov 30 13:29:36 [initandlisten] build index done.  scanned 2549 total
    records. 0.008 secs

    Fri Nov 30 13:29:36 [initandlisten]  bd_production.change_sets
    Assertion failure isOk() src/mongo/db/pdfile.h 360

  0x879d86a 0x85a9835 0x85e441e 0x84caa02 0x84c7d19 0x8229b5a 0x822bfd8
 0x875bd51 0x875f0c7 0x8760df4 0x83e6523 0x83b6c3b 0x8753b07 0x83b92bf
 0x8827ab7 0x882a53b 0x882d4bf 0x882d691 0x85ed280 0x81719dc

 mongod(_ZN5mongo15printStackTraceERSo+0x2a) [0x879d86a]

 mongod(_ZN5mongo10logContextEPKc+0xa5) [0x85a9835]
 ...
 ...
 ...
    ... some error msg 

    Fri Nov 30 13:29:36 [initandlisten] assertion 0 assertion
     src/mongo/db/pdfile.h:360 ns:bd_production.change_sets
    query:{}

     Fri Nov 30 13:29:36 [initandlisten] problem detected during query over
     bd_production.change_sets : { $err: "assertion
     src/mongo/db/pdfile.h:360" }

    Fri Nov 30 13:29:36 [initandlisten] query
    bd_production.change_sets ntoreturn:0 keyUpdates:0 exception:
    assertion src/mongo/db/pdfile.h:360  reslen:71 197ms

     Fri Nov 30 13:29:36 [initandlisten] exception in initAndListen: 13106
     nextSafe(): { $err: "assertion src/mongo/db/pdfile.h:360" }, terminating

     Fri Nov 30 13:29:36 dbexit:
    ...
    ...

新闻集合已成功修复,但“change_set”未成功修复。

如何修复特定的集合(change_set)或数据库?

更新: 当我使用 --repair 为该 change_set 集合运行 mongodump 时,我收到以下错误消息:

Tue Dec  4 10:45:21 [tools]         backwards extent pass
Tue Dec  4 10:45:21 [tools]             extent loc: 5:1181e000
Tue Dec  4 10:45:21 [FileAllocator] allocating new datafile /home/suvankar/dd/bd_production.5, filling with zeroes...
Tue Dec  4 10:45:21 [FileAllocator] creating directory /home/suvankar/dd/_tmp
Tue Dec  4 10:45:21 [FileAllocator] done allocating datafile /home/suvankar/dd/bd_production.5, size: 511MB,  took 0.042 secs
Tue Dec  4 10:45:21 [tools]                 warning: Extent not ok magic: 0 going to try to continue
Tue Dec  4 10:45:21 [tools]                 length:0
Tue Dec  4 10:45:21 [tools]                     ERROR: offset is 0 for record which should be impossible
Tue Dec  4 10:45:21 [tools]                     wrote 1 documents
Tue Dec  4 10:45:21 [tools]             extent loc: 0:0
Tue Dec  4 10:45:21 [tools]                 ERROR: invalid extent ofs: 0
Tue Dec  4 10:45:21 [tools]                  5 objects
Tue Dec  4 10:45:21 dbexit: 
Tue Dec  4 10:45:21 [tools] shutdown: going to close listening sockets...
Tue Dec  4 10:45:21 [tools] shutdown: going to flush diaglog...
Tue Dec  4 10:45:21 [tools] shutdown: going to close sockets...
Tue Dec  4 10:45:21 [tools] shutdown: waiting for fs preallocator...
Tue Dec  4 10:45:21 [tools] shutdown: lock for final commit...

【问题讨论】:

    标签: mongodb ruby-on-rails-3 database


    【解决方案1】:

    如果 mongod with repair 没有执行此操作,那么它会遇到无法修复或解决的损坏级别,因为要启动一组有效且正确的数据库文件。

    您可以运行mongodump with repair,它在试图绕过损坏方面更具侵略性,并且不会启动mongod 实例(因此不需要文件正确即可继续)。

    mongodump --repair --dbpath /var/lib/mongodb/ <other options here>
    

    但请注意,由于它试图绕过损坏的方式,您最终可能会得到一个文档的多个副本。对于mongorestore 的工作方式,这不是问题,但根据损坏程度,您最终可能会得到比您预期大得多的转储文件。在一个非常极端的情况下,我曾经看到产生了 10 倍的数据,尽管那是例外而不是规则。

    在您满意地倾倒所有内容后,开始 mongod clean 并重新导入以恢复良好状态。

    【讨论】:

    • 当我运行以下命令时,我收到以下错误消息:$ sudo mongodump --repair --dbpath /var/lib/mongodb If you are running a mongod on the same path you should connect to that instead of direct data file access Mon Dec 3 21:53:14 dbexit: Mon Dec 3 21:53:14 [tools] shutdown: going to close listening sockets... Mon Dec 3 21:53:14 [tools] shutdown: going to flush diaglog... . Mon Dec 3 21:53:14 [tools] shutdown: closing all files... Mon Dec 3 21:53:14 [tools] closeAllFiles() finished Mon Dec 3 21:53:14 dbexit: really exiting now
    • 好的,有几件事 - 1. 当你尝试这个时,MongoDB 不应该运行 - 我不认为它是,但只是为了确定; 2.您可能应该指定我们的输出目录(请参阅我链接的命令页面上的选项); 3.您应该指定您尝试转储的数据库(使用--db)和可选的集合(--collection) - 基本上我的示例命令就是这样,一个示例,您需要根据您的需要提供一个完整的命令让它工作
    • 我已经更正了使用 mongodump 运行修复的命令......但没有运气!!我收到的错误消息在我的问题的更新部分。执行命令后,它会创建一个空的 change_set.bson 文件,但不会创建元数据文件。其他收藏品工作正常。
    • 恐怕它看起来太严重了,以至于它根本无法理解这个集合。如果您使用 --db bd_production(没有 --collection)运行 mongodump,那么这就是您将获得的最佳效果
    • mongodump with repair 在尝试修复损坏方面基本上和它一样好,如果它没有获得第 9/10 个集合,那么它们的范围太损坏而无法恢复任何东西 -我唯一可以推荐的另一件事是确保您拥有最新的 mongodump(甚至可以尝试开发版本),并且作为最后的手段,如果您认为您知道损坏的集合所在的位置,您可以尝试将该文件移出文件夹,看看是否完全跳过它有助于 mongodump 走得更远
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-02-08
    • 2019-02-16
    • 2018-04-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多