SERVER-15369损坏后恢复数据库

时间:2015-07-02 12:34:13

标签: mongodb

我们有一个dev数据库因this issue而被破坏。有没有办法从数据库中恢复内容?如果我重新编译mongod以便 nsToDatabaseSubstring 总是返回我需要的结果或者没有任何意义怎么办?我只有一个数据库。

2015-07-02T11:51:53.410+0000 I CONTROL  [initandlisten] db version v3.0.4
2015-07-02T11:51:53.410+0000 I CONTROL  [initandlisten] git version: 0481c958daeb2969800511e7475dc66986fa9ed5
2015-07-02T11:51:53.411+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
2015-07-02T11:51:53.411+0000 I CONTROL  [initandlisten] build info: Linux ip-10-146-31-239 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 BOOST_LIB_VERSION=1_49
2015-07-02T11:51:53.411+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2015-07-02T11:51:53.411+0000 I CONTROL  [initandlisten] options: { storage: { journal: { enabled: false } } }
[New Thread 0x7ffff4c17700 (LWP 357)]
2015-07-02T11:51:53.412+0000 I STORAGE  [initandlisten] info openExisting file size 16777216 but mmapv1GlobalOptions.smallfiles=false: /data/db/meteor.0
2015-07-02T11:51:53.414+0000 I -        [initandlisten] Invariant failure _name == nsToDatabaseSubstring( ns ) src/mongo/db/catalog/database.cpp 439
2015-07-02T11:51:53.419+0000 I CONTROL  [initandlisten] 
 0xf7a0f9 0xf19121 0xefdae2 0x939df2 0x939eef 0x93be33 0x93e9a0 0x826781 0x7f2829 0x7ffff6650ead 0x823da9
----- BEGIN BACKTRACE -----
{"backtrace":[{"b":"400000","o":"B7A0F9"},{"b":"400000","o":"B19121"},{"b":"400000","o":"AFDAE2"},{"b":"400000","o":"539DF2"},{"b":"400000","o":"539EEF"},{"b":"400000","o":"53BE33"},{"b":"400000","o":"53E9A0"},{"b":"400000","o":"426781"},{"b":"400000","o":"3F2829"},{"b":"7FFFF6632000","o":"1EEAD"},{"b":"400000","o":"423DA9"}],"processInfo":{ "mongodbVersion" : "3.0.4", "gitVersion" : "0481c958daeb2969800511e7475dc66986fa9ed5", "uname" : { "sysname" : "Linux", "release" : "4.0.5-boot2docker", "version" : "#1 SMP Tue Jun 16 01:39:56 UTC 2015", "machine" : "x86_64" }, "somap" : [ { "elfType" : 2, "b" : "400000", "buildId" : "EB7A0F7D9F202DB3ADD7637D20509D9DE82AC5A1" }, { "b" : "7FFFF7FFA000", "elfType" : 3, "buildId" : "04D43C53E5366F8375342F884E4E2D09CD5964C0" }, { "b" : "7FFFF7BC1000", "path" : "/lib/x86_64-linux-gnu/libpthread.so.0", "elfType" : 3, "buildId" : "FEF281218797AD6AE726DD5FCEDECADD9E9F51DC" }, { "b" : "7FFFF7960000", "path" : "/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0", "elfType" : 3, "buildId" : "ED2B7FC51D2E7ADD0D4F1A3667E2B6ED7257663F" }, { "b" : "7FFFF7568000", "path" : "/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", "elfType" : 3, "buildId" : "7C7F328E0814F339D251A8F8C9459E50978EC254" }, { "b" : "7FFFF7360000", "path" : "/lib/x86_64-linux-gnu/librt.so.1", "elfType" : 3, "buildId" : "F58D5DE3E7A2989E915422BA4203FE53DBA449A0" }, { "b" : "7FFFF715C000", "path" : "/lib/x86_64-linux-gnu/libdl.so.2", "elfType" : 3, "buildId" : "5D1CA3A3D93ED5B6C6462FFA03E787FDBE4013A3" }, { "b" : "7FFFF6E55000", "path" : "/usr/lib/x86_64-linux-gnu/libstdc++.so.6", "elfType" : 3, "buildId" : "8711429397A5AF8B6269B867D830EDF6E0225B8D" }, { "b" : "7FFFF6BD3000", "path" : "/lib/x86_64-linux-gnu/libm.so.6", "elfType" : 3, "buildId" : "7F58D6664571941C86B2D969701A572AD4D7BF1D" }, { "b" : "7FFFF69BD000", "path" : "/lib/x86_64-linux-gnu/libgcc_s.so.1", "elfType" : 3, "buildId" : "F980B1188708F8D8B5C35D185444AF4CB939AA1E" }, { "b" : "7FFFF6632000", "path" : "/lib/x86_64-linux-gnu/libc.so.6", "elfType" : 3, "buildId" : "A745EBA2C16BA80AE1EF1A7A7B70740C2CF1B363" }, { "b" : "7FFFF7DDD000", "path" : "/lib64/ld-linux-x86-64.so.2", "elfType" : 3, "buildId" : "9B23F2A44CC8CA6175CBD8D64584B1C7EA5FD18C" }, { "b" : "7FFFF641B000", "path" : "/lib/x86_64-linux-gnu/libz.so.1", "elfType" : 3, "buildId" : "1EFEB71FD4999C2307570D673A724EA4E1D85267" } ] }}

UPD:在DigitalOcean上运行时文件已损坏,因此我不确定他们使用的虚拟化软件。我目前正在尝试使用VMWare 4.3.28和docker。 基本上谷歌搜索指向我this线程,所以我认为它已被损坏,因为 SERVER-15369 。 我们没有较旧的备份,因此我们必须修复数据库或重写所有需要花费大量时间的内容。不幸的是,就是这样。我知道备份数据的重要性,但它刚刚发生。

UPD 2:已修复 所以我能够恢复日期,我运行一个新的mongo实例,将我的db文件复制回数据文件夹。然后在mongo控制台内部我将数据保存在磁盘上并关闭数据库。在我再次运行之后,我能够看到并转储我的数据。

0 个答案:

没有答案