我们在我们的数据库中使用了mongodb，并设置了replset（两个服务器），但是我们错误地删除了两个服务器上的/ path / to / dbdata下的一些原始文件。 之后，我们使用extundelete来取回已删除的文件。 我们在两台服务器上运行了extundelete ，并合并了结果，如database.1，database.2等。我们无法启动mongod，在启动mongod或执行mongodump时出现以下错误，这里是控制台输出：
root@mongod:/opt/mongodb# mongodump --repair --dbpath /opt/mongodb -d database_production Thu Aug 21 16:22:43.258 [tools] warning: repair is a work in progress Thu Aug 21 16:22:43.258 [tools] going to try and recover data from: database_production Thu Aug 21 16:22:43.262 [tools] Assertion failure isOk() src/mongo/db/pdfile.h 392 0xde1b01 0xda42fd 0x8ae325 0x8ac492 0x8bd8e0 0x8c1c51 0x80e345 0x80e607 0x80e6a4 0x6db92a 0x6dc1ff 0x6e0db9 0xd9e45e 0x6ccdc7 0x7f499d856ead 0x6ccc29 mongodump(_ZN5mongo15printStackTraceERSo+0x21) [0xde1b01] mongodump(_ZN5mongo12verifyFailedEPKcS1_j+0xfd) [0xda42fd] mongodump(_ZNK5mongo7Forward4nextERKNS_7DiskLocE+0x1a5) [0x8ae325] mongodump(_ZN5mongo11BasicCursor7advanceEv+0x82) [0x8ac492] mongodump(_ZN5mongo8Database19clearTmpCollectionsEv+0x160) [0x8bd8e0] mongodump(_ZN5mongo14DatabaseHolder11getOrCreateERKSsS2_Rb+0x7b1) [0x8c1c51] mongodump(_ZN5mongo6Client7Context11_finishInitEv+0x65) [0x80e345] mongodump(_ZN5mongo6Client7ContextC1ERKSsS3_b+0x87) [0x80e607] mongodump(_ZN5mongo6Client12WriteContextC1ERKSsS3_+0x54) [0x80e6a4] mongodump(_ZN4Dump7_repairESs+0x3a) [0x6db92a] mongodump(_ZN4Dump6repairEv+0x2df) [0x6dc1ff] mongodump(_ZN4Dump3runEv+0x1b9) [0x6e0db9] mongodump(_ZN5mongo4Tool4mainEiPPc+0x13de) [0xd9e45e] mongodump(main+0x37) [0x6ccdc7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f499d856ead] mongodump(__gxx_personality_v0+0x471) [0x6ccc29] assertion: 0 assertion src/mongo/db/pdfile.h:392 Thu Aug 21 16:22:43.271 dbexit: Thu Aug 21 16:22:43.271 [tools] shutdown: going to close listening sockets... Thu Aug 21 16:22:43.271 [tools] shutdown: going to flush diaglog... Thu Aug 21 16:22:43.271 [tools] shutdown: going to close sockets... Thu Aug 21 16:22:43.272 [tools] shutdown: waiting for fs preallocator... Thu Aug 21 16:22:43.272 [tools] shutdown: closing all files... Thu Aug 21 16:22:43.273 [tools] closeAllFiles() finished Thu Aug 21 16:22:43.273 [tools] shutdown: removing fs lock... Thu Aug 21 16:22:43.273 dbexit: really exiting now
我的环境：
而我们并没有删除.0和.ns文件。
我们试着用相同的名字创build一个新的数据库，并将这些db.ns和db.2 ， db.3到新的数据库中，但是我们仍然遇到了同样的错误。
有没有办法检查原始.ns和数据文件的有效性，以及如何恢复数据库？
正如Stennie正确指出的那样，您的数据几乎肯定会丢失。
原因是MongoDB复制不是数据文件的二进制复制。 相反，优化的语句被保存在一个名为“oplog”的特殊集合中，这些特殊的集合通过一个可拖动的光标连接到辅助数据库。 当MongoDB优化查询时，将其写入到所述oplog中，并且所连接的次级可以读取所得到的一个或多个查询。
因此，根据初始化复制时副本集的数据文件所处的状态，同一文档可能驻留在主数据文件1中，而驻留在一个辅助数据库中的数据文件42中，另一个副本上驻留数据文件3。 底线是文件在数据文件中的位置是不可预测的，更不用说了。
我讨厌这么说，但是除了极其昂贵的数据取证之外，你的数据是无法恢复的。
尽pipe它可以被描述为“第一个连续的自由范围的字节，能够保存文档的数据和填充的二进制表示”。