Мы используем mongodb для нашей базы данных и устанавливаем набор реплик (два сервера), но мы по ошибке удалили некоторые необработанные файлы, которые находятся в / 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
Мой env:
и мы не удалили .0 и .ns файлы.
Мы попытались создать новую базу данных с таким же именем и скопировать эти db.ns и db.2, db.3 в новую базу данных мы все еще встречали ту же ошибку.
Есть ли способ проверить действительность необработанных .ns и файлов данных и как восстановить базу данных?
Как правильно заметил Стенни, ваши данные почти наверняка потеряны.
Причина этого в том, что репликация MongoDB - это не двоичная репликация файлов данных. Вместо этого оптимизированные операторы сохраняются в специальной коллекции под названием «oplog», к которой второстепенные операторы подключаются с помощью настраиваемого курсора. Когда MongoDB оптимизировал запрос, он записывается в указанный журнал операций, и подключенные вторичные серверы могут читать результирующий запрос или запросы.
Следовательно, в зависимости от того, в каком состоянии находились файлы данных набора реплик при инициализации репликации, один и тот же документ может находиться в файле данных 1 на первичном сервере, в то время как он находится в файле данных 42 на одном вторичном сервере и файле данных 3 на другом. Суть в том, что положение документа в файлах данных не предсказуемо *, а тем более гарантировано.
Ненавижу это говорить, но, если не считать чрезвычайно дорогостоящей экспертизы данных, ваши данные невозможно восстановить.
*Хотя его можно описать как «Первый непрерывный свободный диапазон байтов, способный содержать двоичное представление данных документа и заполнения».