Ich führe Mongodb auf einer AWS EC2-Instanz aus. Daten/Protokoll/und Journal werden in einem separaten Volume gespeichert, das als xfs formatiert ist. Derzeit stoppen wir die Mongodb-Instanz, um einen Snapshot zu erstellen, lesen aber Folgendes: https://docs.mongodb.com/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2/ anscheinend besteht keine Notwendigkeit, den Dienst während des Snapshots anzuhalten, da das Journal aktiviert ist. Habe ich Recht? Kann ich einen konsistenten Snapshot erstellen, auch wenn der Dienst ausgeführt wird?
Antwort1
Vertrauen Sie grundsätzlich keinem Sicherungsverfahren, bis Sie die Integrität einer Wiederherstellung von einem Langzeitmedium bestätigt haben.
Sie haben bereits die Möglichkeit, online ein Backup auf Speichersystemebene durchzuführen. In diesem Fall mit EBS-Volumes oder Linux LVM. Das Problem besteht darin, die Datenbank in einen konsistenten Zustand zu bringen.
Ein Online-Backup ist mit oder ohne Journal möglich. In beiden Fällen kann Mongo Datenbankschreibvorgänge mit fsync und lock anhalten, wie in diesem Tutorial beschrieben.
Ohne Journal lässt sich nur schwer feststellen, welche Daten auf der Festplatte dauerhaft gespeichert sind und welche gepuffert und noch nicht festgeschrieben wurden. fsync und lock legen einen Zeitpunkt fest und stoppen alle weiteren laufenden Schreibvorgänge, bis die Sicherung abgeschlossen ist.
Die Sperre ist auch bei mehreren Festplatten erforderlich, bei denen (auf diesem Speichersystem) die Snapshots nicht miteinander konsistent sind. Das Aussetzen von Schreibvorgängen für die Dauer der Sicherung bedeutet, dass die Festplatte /dev/sdfnicht zu einem leicht anderen Zeitpunkt als ist /dev/sdg.
Mongo behauptet, dass, wenn Sie nur eineeinzelFestplatte undhabenein Journal, Sie müssen weder fsync noch locken. Vermutlich ist der EBS-Snapshot ein ausreichend guter, absturzsicherer Zeitpunkt, und die Journal-Forward-Recovery kann unvollständige Schreibvorgänge reparieren.