Mongo DB Invariante guasto

Question

Il nostro DB di + - 400 Gb si sta arrestando sul nostro unico server.

Dal registro:

2015-07-07T09:09:51.072+0200 I STORAGE [conn10] _getOpenFile() invalid file index requested 8388701 
2015-07-07T09:09:51.072+0200 I -  [conn10] Invariant failure false src/mongo/db/storage/mmap_v1/mmap_v1_extent_manager.cpp 201 
2015-07-07T09:09:51.082+0200 I CONTROL [conn10] 

Qualche idea in quelli che sono dovrei iniziare a cercare? Problema di archiviazione?

Answer 1

Mi sono imbattuto in una variante di questo oggi pure. Misteriosamente uno dei miei file di dati è scomparso (o non lo ha fatto in una migrazione da un altro server). Nessuna delle procedure di riparazione/ripristino funzionerebbe, in mancanza dello stesso errore a cui si fa riferimento. Fortunatamente ho un file distinto che ha una collezione con lo stesso nome, così come un hack economico ho copiato il file di dati (dichiaratamente sbagliato) sull'altro server, e mentre sapevo che non avrei recuperato alcun dato, gli strumenti di riparazione (come mongod --repair) erano quindi in grado di lavorare la loro magia, ma come previsto, hanno recuperato alcuni dati dal file errato che ho copiato, quindi ho dovuto estirpare alcuni documenti. Fortunatamente era il file "mycollection.1", che è solo 128MB.

Non penso che ciò si applichi nel tuo caso, dal momento che l'indice del file di dati mancanti di cui parla il tuo registro è incredibilmente alto. Il tuo log in sostanza dice che non riesce a trovare /data/dbname/mycollection.8388701. Hai detto che il tuo set di dati è solo di 400 GB, quindi un indice così alto non ha senso. Dovresti avere solo circa 200 file di dati poiché la maggior parte di essi sono 2 GB ciascuno per impostazione predefinita. Qual è il risultato di db.stats() (in particolare l'attributo fileSize)?

Questo mongolab blog entry mi ha aiutato a capire la struttura del file di dati.

Il mio consiglio per dove si dovrebbe cominciare a guardare:

1. eseguire il comando db.stats() per avere un'idea di come i dati sul disco grande è in realtà.
2. Ha senso che il server cerchi un file di dati con un indice elevato pazzo? In caso contrario, il problema non riguarda realmente l'archiviazione, ma le estensioni e i metadati della raccolta/database.
3. Gli strumenti di riparazione funzionano? Se si dispone di almeno sufficiente spazio libero su disco come dimensione del set di dati (su disco), provare gli strumenti mongod --repair o db.repairDatabase() per avviare una riparazione. Suppongo che non funzionerà poiché i miei tentativi di riparazione si sono interrotti con lo stesso errore invalid file index requested.
4. Provare a copiare un file "cattivo" come quello che ho fatto corrisponde approssimativamente a quello che sarebbe il file mancante (tenendo presente che le dimensioni dei file dei file di dati non sono tutte uguali, fai del tuo meglio per abbinarle e prova una riparazione). Se funziona, i file di dati verranno ripuliti (ma richiede molto spazio su disco).

La speranza che ti aiuta a orientarti nella giusta direzione.

Answer 2

sto solo rispondere a questa domanda nel caso in cui alcune persone fanno lo stesso errore non tecnico ancora:

ho cercato di scp tutti i file nella directory /data/db al server. Poiché i file sono molti (dbname.1 a dbname.55, circa 100 GB), è stato interrotto a metà (ultimo file riuscito dbname.22) e ho riavviato e caricato dbname.23 in dbname.55. E quando eseguo le query nel client mongo, ha funzionato per alcuni casi e non è riuscito per altri mostrando il messaggio di errore come nella domanda. Ho pensato che potesse esserci qualche file rotto nel trasferimento dei file, ma il controllo md5 andava bene.Solo dopo aver passato molto tempo a terminare tutto il controllo MD5, ho trovato il motivo.

si è rivelato essere che arrivi scpdbname.21-dbname.29 dopo la carica dbname.2, così dbname.3 a dbname.9 non è mai stato caricato sul server. Ho intenzione di caricarli, e questo dovrebbe risolvere il problema.