É possível recuperar bancos de dados MongoDB de .ns e .0, .1,. … arquivos?


14

Eu tenho uma instalação do MongoDB 2.0.4 no Ubuntu 12.10. Recentemente, tive alguns problemas ao conectar-me ao banco de dados de fora e descobri que havia algo que impedia o MongoDB de iniciar corretamente. Conforme sugerido em várias fontes (consulte StackOverflow), removi /var/lib/mongodb/mongodb.locke executei mongod --repair. Isso não resolveu o problema, o MongoDB não funcionava e continuava criando arquivos de bloqueio que não eram necessários para remover depois. Ao olhar para os logs, percebi que ele não tinha acesso a uma pasta chamada $tmpSomething, então (como o nome sugeria uma pasta temporária) eu a removi e depois tudo funcionou ... exceto pelo fato de eu ter apenas uma. dos meus bancos de dados anteriores à vista, enquanto os outros ainda estão lá porque minha /var/lib/mongodb/pasta ainda está cheia de.ns .0 .1 .narquivos que pesam muito. Existe uma maneira de restaurá-los no banco de dados? (Eu tentei com o mongorestore, mas como eu esperava, ele não lida com esses arquivos).

obrigado

Respostas:


19

Os .ns .0 .1arquivos etc. são os próprios arquivos de dados. Se você iniciou uma mongodinstância com um --dbpathargumento apontando para essa pasta ou se moveu o conteúdo para outro lugar e usou a opção para apontar para ela, o mongod tentará lê-los normalmente.

Como seus problemas sugerem corrupção e / ou algum outro problema é iniciado mongod(você deve realmente postar os arquivos de log de mensagens de inicialização, talvez em uma pergunta separada para resolver esse problema), existem alternativas. Para referência, os problemas mais comuns estão relacionados às permissões, especialmente quando as pessoas tentam iniciar o mongod manualmente (como elas mesmas) ou com o sudo (como root) e criar permissões problemáticas nos vários diretórios.

Você está certo que mongorestorenão pode usar esses arquivos de dados diretamente, mas mongodumppode lê-los e despejar dados deles nos arquivos BSON que mongorestoreespera.

A opção que você deseja aqui é dbpath . Você mencionou que seu caminho é /var/lib/mongo, portanto, você pode executar algo como isto:

mongodump --dbpath /var/lib/mongo -d <database name> -o /path/to/put/files

Opcionalmente, você também pode usar --repairaqui para corrigir a corrupção, juntamente com as opções de consulta em circunstâncias extremas, para contornar as seções corrompidas (raramente, se é que alguma vez for necessário). As várias opções estão descritas na mongodumppágina:

http://docs.mongodb.org/manual/reference/mongodump/

Depois de despejar os arquivos, você pode mongorestorereimportá-los para outra mongodinstância.



2
Com Mongo 3.0 uma opção é para iniciar o servidor mongo com arquivos especificados: mongod --dbpath ./e, em seguida, prosseguir com a mongodump sem a--dbpath
Shwaydogg

3
Apenas uma observação, se você estiver executando o Mongo 3.0 e mongod --dbpath ./não fornecer o banco de dados nos .ns .0arquivos, pode ser que o mecanismo de armazenamento esteja padronizando o novo mecanismo WiredTiger em vez do mecanismo MMapV1 antigo. Tente mongod --storageEngine mmapv1 --dbpath ./conectar-se usando o mecanismo antigo.
Flamebaud

1
Alguém pode me ajudar migração de dados do .NS, .0 e .1 arquivos para mongo 3.0
Mandeep Singh

1
Como o @flamebaud disse, o mecanismo padrão mudou. Verifique a alteração do mecanismo de armazenamento padrão na documentação do Mongo. Você também pode dar uma olhada no início do documento em WiredTiger Storage Engine
Ludovic Kuty 7/16/16
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.