Mongodb 服务器-15369损坏后恢复数据库

我们有一个dev数据库，由于以下原因而损坏。有没有办法从数据库中恢复内容？如果我重新编译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运行。 基本上，谷歌搜索将我的线程指向了我的线程，因此我认为它已损坏，因为服务器-15369。 我们没有较旧的备份，所以我们要么修复数据库，要么重新编写所有内容，这将花费大量时间。不幸的是，是这样的。我知道备份数据的重要性，但它只是发生了

UPD 2：已修复

---

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

您是如何诊断您的数据库受到服务器-15369的影响的？您的日志输出来自MongoDB 3.0.4。。您从哪个版本的MongoDB升级，您的Linux内核和VMWare版本是什么？如果数据损坏，重新编译MongoDB以忽略错误/返回“预期”结果是没有意义的。鉴于这是一个开发人员数据库，我倾向于从旧的备份中重建或恢复，而不是在恢复上投入大量时间。@Stennie向问题发布了一个更新