Mongo DB Invariant Fehler

Question

Unsere DB von + - 400 GB stoppt auf unserem einen Server.

Aus den Protokollen:

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] 

Jede Idee, in was soll ich anfangen suchen? Speicherproblem?

Answer 1

Ich bin heute auch auf eine Variante davon gestoßen. Mysteriös ist eine meiner Dateien verschwunden (oder hat es nicht bei einer Migration von einem anderen Server geschafft). Keines der Reparatur-/Wiederherstellungsprozeduren würde funktionieren, wenn derselbe Fehler fehlschlägt, auf den Sie verweisen. Zum Glück habe ich einen separaten Mongod, der eine Sammlung mit dem gleichen Namen hat, so dass ich als billigen Hack die (zugegeben falsche) Datendatei auf den anderen Server kopiert habe, und während ich wusste, dass ich keine Daten zurückbekomme, die Reparaturwerkzeuge (wie mongod --repair) waren dann in der Lage, ihre Magie zu arbeiten, aber wie erwartet, erholten sie einige Daten von der schlechten Datei, die ich kopierte, also musste ich einige Dokumente aussortieren. Zum Glück war es die "mycollection.1" -Datei, die nur 128 MB groß ist.

Ich denke nicht, dass dies in Ihrem Fall gilt, da der Index der fehlenden Datendatei, über die Ihr Protokoll spricht, lächerlich hoch ist. Ihr Protokoll sagt im Wesentlichen, dass es /data/dbname/mycollection.8388701 nicht finden kann. Sie sagten, Ihr Datensatz sei nur 400 GB, also macht ein hoher Index keinen Sinn. Sie sollten nur etwa 200 Datendateien haben, da die meisten standardmäßig 2 GB groß sind. Was ist das Ergebnis von db.stats() (speziell das FileSize-Attribut)?

Diese mongolab blog entry hat mir geholfen, die Datendateistruktur zu verstehen.

Mein Rat für, wo Sie beginnen, sollten:

1. führen Sie den Befehl db.stats() eine Vorstellung davon zu bekommen, wie groß Ihre Daten auf Scheibe tatsächlich ist.
2. Macht es Sinn, dass Ihr Server nach einer Datendatei mit einem verrückten hohen Index sucht? Wenn nicht, ist das Problem nicht wirklich mit Speicher, sondern mit den Extents und den Metadaten Ihrer Sammlung/Datenbank.
3. Funktionieren Ihre Reparaturwerkzeuge? Wenn Sie mindestens über genügend freien Speicherplatz als die Größe Ihres Datensatzes (auf Datenträger) verfügen, versuchen Sie die mongod --repair oder db.repairDatabase() Tools, um eine Reparatur zu starten. Ich gehe davon aus, dass es nicht funktioniert, seit meine Reparaturversuche mit demselben invalid file index requested Fehler abgestürzt sind.
4. Versuchen Sie, eine "schlechte" Datei zu kopieren, so wie ich es ungefähr so ​​gemacht habe, wie die fehlende Datei aussehen würde (beachten Sie, dass die Dateigrößen der Datendateien nicht alle gleich sind) versuche eine Reparatur). Wenn das funktioniert, werden Ihre Datendateien aufgeräumt (aber es braucht viel Speicherplatz).

Hoffe, dass hilft Ihnen in die richtige Richtung.

Answer 2

ich nur diese Frage, falls ich die Beantwortung einige Leute machen den gleichen nicht-technische Fehler wieder:

Ich versuchte scp alle Dateien in dem Verzeichnis /data/db an den Server. Da die Dateien viele sind (bis dbname.55, etwa 100 GB), wurde es in der Mitte unterbrochen (letzte erfolgreiche Datei dbname.22), und ich startete dbname.23 neu gestartet und hochgeladen dbname.55. Und wenn ich Abfragen in mongo Client ausgeführt habe, funktionierte es in einigen Fällen, und für einige andere fehlgeschlagen, die die Fehlermeldung die gleiche wie in der Frage zeigen. Ich dachte, es könnte eine Datei in der Dateiübertragung beschädigt sein, aber die MD5-Prüfung war in Ordnung.Erst nachdem ich lange den md5-Check erledigt hatte, fand ich den Grund.

Es hat sich gezeigt, dass scp Uploads dbname.21-dbname.29 zu sein, nachdem es hochgeladen dbname.2, so dbname.3 zu dbname.9 wurde nie auf den Server hochgeladen. Ich werde sie hochladen, und das sollte das Problem lösen.