Recuperando dados de arquivos raw do MongoDB

2

Usamos o mongodb para nosso banco de dados e configuramos o conjunto de replicação (dois servidores), mas, por engano, excluímos alguns arquivos brutos sob / path / to / dbdata em ambos os servidores. Depois disso, usamos extundelete para recuperar os arquivos excluídos. Nós rodamos o extundelete nos dois servidores e mesclamos os resultados, como database.1, database.2 etc. Nós não pudemos iniciar o mongod, ele gerou o seguinte erro ao iniciar o mongod ou executar o mongodump, aqui está a saída do console:

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

Meu env:

  1. Debian 3.2.35-2 x86_64 (é uma máquina virtual XEN)
  2. mongodb 2.4.6

e não excluímos os arquivos .0 e .ns .

Tentamos criar um novo banco de dados com o mesmo nome e copiar esses db.ns e db.2 , db.3 para o novo banco de dados. Ainda encontramos o mesmo erro.

Existe alguma maneira de verificar a validade de .ns e arquivos de dados, e como recuperar o banco de dados?

    
por Jin Chen 21.08.2014 / 11:40

1 resposta

0

Como Stennie apontou corretamente, seus dados quase certamente foram perdidos.

A razão para isso é que a replicação do MongoDB não é uma replicação binária dos arquivos de dados. Em vez disso, as instruções otimizadas são salvas em uma coleção especial chamada "oplog", à qual os secundários se conectam com um cursor disponível. Quando o MongoDB otimizou uma consulta, ela é gravada no referido oplog e os secundários conectados podem ler a consulta ou as consultas resultantes.

Portanto, dependendo do estado em que os arquivos de dados do conjunto de réplicas estavam quando você inicializou a replicação, o mesmo documento pode residir no arquivo de dados 1 no primário enquanto ele reside no arquivo de dados 42 em um secundário e no arquivo de dados 3 em outro. A conclusão é que a posição de um documento nos arquivos de dados não é previsível *, muito menos a garantia.

Eu odeio dizer isso, mas, exceto pelos dados forenses extremamente caros, seus dados são irrecuperáveis.

* Embora seja descrito como "O primeiro intervalo contínuo livre de bytes capaz de manter a representação binária dos dados do documento e preenchimento".

    
por 26.10.2014 / 15:38

Tags