È possibile recuperare i database MongoDB da .ns e .0, .1,. … File?


14

Ho un'installazione MongoDB 2.0.4 su Ubuntu 12.10. Recentemente ho avuto alcuni problemi di connessione al database dall'esterno e ho capito che c'era qualcosa che impediva a MongoDB di avviarsi correttamente. Come suggerito su diverse fonti (vedi StackOverflow) ho rimosso /var/lib/mongodb/mongodb.locked eseguito mongod --repair. Questo non risolveva il problema, MongoDB non funzionava e continuava a creare file di blocco che non si occupava di rimuovere in seguito. Guardando i registri, mi sono reso conto che non aveva accesso a una cartella chiamata $tmpSomething, quindi (poiché il nome suggeriva una cartella temporanea) l'ho rimosso, e poi ha funzionato tutto ... tranne il fatto che ne ho solo una dei miei precedenti database in vista, mentre gli altri sono ancora lì perché la mia /var/lib/mongodb/cartella è ancora piena.ns .0 .1 .nfile che pesano molto. C'è un modo per ripristinarli nel database? (Ho provato con mongorestore, ma come mi aspettavo, non gestisce quei file).

Grazie

Risposte:


19

I .ns .0 .1file ecc. Sono i file di dati stessi. Se hai avviato mongodun'istanza con un --dbpathargomento che punta a quella cartella o se hai spostato i contenuti da qualche altra parte e hai utilizzato l'opzione per puntare lì, mongod tenterà di leggerli normalmente.

Poiché i tuoi problemi suggeriscono che la corruzione e / o qualche altro problema si avviino mongod(dovresti davvero pubblicare i file di registro dei messaggi di avvio, forse in una domanda separata per risolvere il problema), quindi ci sono alternative. Per riferimento, i problemi più comuni sono legati alle autorizzazioni, specialmente quando le persone cercano di avviare mongod manualmente (come loro stessi) o con sudo (come root) e creare autorizzazioni problematiche nelle varie directory.

Hai ragione che mongorestorenon è possibile utilizzare direttamente questi file di dati, ma è mongodumppossibile leggerli e scaricare i dati da essi nei file BSON previsti mongorestore.

L'opzione che vuoi qui è dbpath . Dici che il tuo percorso è /var/lib/mongo, quindi puoi eseguire qualcosa del genere:

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

Opzionalmente puoi usare --repairanche qui per correggere la corruzione insieme alle opzioni di query in circostanze estreme per aggirare le sezioni danneggiate (raramente, se mai, necessarie). Le varie opzioni sono descritte nella mongodumppagina:

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

Dopo aver scaricato i file, è possibile utilizzarli mongorestoreper reimportarli in un'altra mongodistanza.



2
Con Mongo 3.0 un'opzione è avviare il server mongo con i file specificati: mongod --dbpath ./e quindi procedere con il mongodump senza il--dbpath
Shwaydogg

3
Solo una nota, se stai eseguendo Mongo 3.0 e mongod --dbpath ./non ti fornisce il database nei .ns .0file, potrebbe essere che il motore di archiviazione sia predefinito sul nuovo motore WiredTiger invece che sul vecchio motore MMapV1. Prova mongod --storageEngine mmapv1 --dbpath ./invece a connetterti utilizzando il vecchio motore.
flamebaud,

1
Qualcuno può aiutarmi a migrare i dati dai file .ns, .0 e .1 a mongo 3.0
Mandeep Singh,

1
Come diceva @flamebaud, il motore predefinito è cambiato. Controlla la modifica del motore di archiviazione predefinito nella documentazione Mongo. Potresti anche dare un'occhiata all'inizio del documento a WiredTiger Storage Engine
Ludovic Kuty
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.