Produktionsausfälle werden fast garantiert irgendwann auftreten. Wenn Sie diese Tatsache akzeptieren und den Zeitplan und das Fehlerszenario Ihres Datenbankausfalls analysieren, können Sie den nächsten Ausfall besser vorbereiten, diagnostizieren und wiederherstellen. Um die Auswirkungen von Ausfallzeiten zu mindern, benötigen Unternehmen einen geeigneten Notfallwiederherstellungsplan (DR). Die DR-Planung ist für viele SysOps/DevOps eine kritische Aufgabe, aber obwohl sie vorgesehen ist; oft existiert es nicht.
In diesem Blogbeitrag analysieren wir verschiedene Sicherungs- und Ausfallszenarien in MongoDB-Datenbanksystemen. Wir führen Sie auch durch die Wiederherstellungs- und Failover-Verfahren für das jeweilige Szenario. Diese Anwendungsfälle unterscheiden sich von der Wiederherstellung eines einzelnen Knotens, der Wiederherstellung eines Knotens in einem vorhandenen Replikatsatz und dem Seeding eines neuen Knotens in einem Replikatsatz. Hoffentlich vermittelt Ihnen dies ein gutes Verständnis der Risiken, denen Sie möglicherweise ausgesetzt sind, und was Sie beim Entwerfen Ihrer Infrastruktur berücksichtigen sollten.
Bevor wir mit der Diskussion möglicher Ausfallszenarien beginnen, werfen wir einen Blick darauf, wie MongoDB Daten speichert und welche Arten von Backups verfügbar sind.
Wie MongoDB Daten speichert
MongoDB ist eine dokumentenorientierte Datenbank. Anstatt Ihre Daten in Tabellen zu speichern, die aus einzelnen Zeilen bestehen (wie es eine relationale Datenbank tut), speichert sie Daten in Sammlungen, die aus einzelnen Dokumenten bestehen. In MongoDB ist ein Dokument ein großer JSON-Blob ohne bestimmtes Format oder Schema. Darüber hinaus können Daten per Sharing auf verschiedene Cluster-Knoten verteilt oder mit replicaSet auf Slave-Server repliziert werden.
MongoDB ermöglicht standardmäßig sehr schnelle Schreibvorgänge und Aktualisierungen. Der Nachteil besteht darin, dass Sie häufig nicht explizit über Fehler benachrichtigt werden. Standardmäßig führen die meisten Treiber asynchrone, unsichere Schreibvorgänge durch. Das bedeutet, dass der Treiber nicht direkt einen Fehler zurückgibt, ähnlich wie INSERT DELAYED bei MySQL. Wenn Sie wissen möchten, ob etwas erfolgreich war, müssen Sie manuell mit getLastError nach Fehlern suchen.
Für eine optimale Leistung ist es vorzuziehen, SSD statt HDD als Speicher zu verwenden. Es ist notwendig, darauf zu achten, ob Ihr Speicher lokal oder remote ist, und entsprechende Maßnahmen zu ergreifen. Es ist besser, RAID zum Schutz vor Hardwaredefekten und Wiederherstellungsschemata zu verwenden, aber verlassen Sie sich nicht vollständig darauf, da es keinen Schutz vor unerwünschten Ausfällen bietet. Die richtige Hardware ist der Baustein für Ihre Anwendung, um die Leistung zu optimieren und ein größeres Debakel zu vermeiden.
Datenbeschädigung auf Datenträgerebene oder fehlende Datendateien können verhindern, dass Mongod-Instanzen gestartet werden, und Journaldateien reichen möglicherweise nicht aus, um automatisch wiederhergestellt zu werden.
Wenn Sie mit aktiviertem Journaling arbeiten, müssen Sie fast nie eine Reparatur ausführen, da der Server die Journaldateien verwenden kann, um die Datendateien automatisch in einem sauberen Zustand wiederherzustellen. In Fällen, in denen Sie eine Datenbeschädigung auf Datenträgerebene wiederherstellen müssen, müssen Sie jedoch möglicherweise immer noch eine Reparatur durchführen.
Wenn Journaling nicht aktiviert ist, besteht Ihre einzige Option möglicherweise darin, den Reparaturbefehl auszuführen. mongod --repair sollte nur verwendet werden, wenn Sie keine anderen Optionen haben, da die Operation beschädigte Daten während des Reparaturvorgangs entfernt (und nicht speichert). Dieser Art von Vorgang sollte immer eine Sicherung vorangehen.
MongoDB-Notfallwiederherstellungsszenario
In einem Wiederherstellungsplan nach einem Ausfall ist Ihr Recovery Point Objective (RPO) ein wichtiger Wiederherstellungsparameter, der bestimmt, wie viele Daten Sie sich leisten können, zu verlieren. RPO wird in der Zeit aufgelistet, von Millisekunden bis zu Tagen, und hängt direkt von Ihrem Backup-System ab. Es berücksichtigt das Alter Ihrer Sicherungsdaten, die Sie wiederherstellen müssen, um den normalen Betrieb wieder aufzunehmen.
Um den RPO zu schätzen, müssen Sie sich einige Fragen stellen. Wann werden meine Daten gesichert? Welches SLA ist mit dem Abruf der Daten verbunden? Ist das Wiederherstellen einer Sicherungskopie der Daten akzeptabel oder müssen die Daten online und jederzeit abrufbar sein?
Antworten auf diese Fragen werden Ihnen dabei helfen, welche Art von Sicherungslösung Sie benötigen.
MongoDB-Sicherungslösungen
Sicherungstechniken haben unterschiedliche Auswirkungen auf die Leistung der laufenden Datenbank. Einige Backup-Lösungen beeinträchtigen die Datenbankleistung so stark, dass Sie möglicherweise Backups planen müssen, um Spitzenlasten oder Wartungsfenster zu vermeiden. Sie können beschließen, neue sekundäre Server bereitzustellen, nur um Backups zu unterstützen.
Die drei gängigsten Lösungen zum Sichern Ihres MongoDB-Servers/Clusters sind...
- Mongodump/Mongorestore - logisches Backup.
- Mongo Management System (Cloud) – Produktionsdatenbanken können mit MongoDB Ops Manager gesichert werden, oder wenn Sie den MongoDB Atlas-Dienst verwenden, können Sie eine vollständig verwaltete Sicherungslösung verwenden.
- Datenbank-Snapshots (Backup auf Laufwerksebene)
Mongodump/Mongorestore
Bei der Durchführung eines Mongodump werden alle Sammlungen in den angegebenen Datenbanken als BSON-Ausgabe ausgegeben. Wenn keine Datenbank angegeben wird, sichert MongoDB alle Datenbanken mit Ausnahme der Admin-, Test- und lokalen Datenbanken, da diese für den internen Gebrauch reserviert sind.
Standardmäßig erstellt mongodump ein Verzeichnis namens dump, mit einem Verzeichnis für jede Datenbank, die eine BSON-Datei pro Sammlung in dieser Datenbank enthält. Alternativ können Sie mongodump anweisen, das Backup in einer einzigen Archivdatei zu speichern. Der Parameter archive verkettet die Ausgabe aller Datenbanken und Sammlungen zu einem einzigen Strom binärer Daten. Zusätzlich kann der gzip-Parameter dieses Archiv natürlich mit gzip komprimieren. In ClusterControl streamen wir alle unsere Backups, also aktivieren wir sowohl die Archiv- als auch die gzip-Parameter.
Ähnlich wie mysqldump mit MySQL, wenn Sie ein Backup in MongoDB erstellen, werden die Sammlungen eingefroren, während der Inhalt in die Backup-Datei geschrieben wird. Da MongoDB keine Transaktionen unterstützt (geändert in 4.2), können Sie kein 100 % vollständig konsistentes Backup erstellen, es sei denn, Sie erstellen das Backup mit dem oplog-Parameter. Wenn Sie dies für die Sicherung aktivieren, werden die Transaktionen aus dem Oplog eingeschlossen, die während der Erstellung der Sicherung ausgeführt wurden.
Für eine bessere Automatisierung können Sie MongoDB über die Befehlszeile ausführen oder externe Tools wie ClusterControl verwenden. ClusterControl ist eine empfohlene Option für Backup-Management und Backup-Automatisierung, da es die Erstellung fortschrittlicher Backup-Strategien für verschiedene Open-Source-Datenbanksysteme ermöglicht.
ClusterControl ermöglicht Ihnen, Ihr Backup in die Cloud hochzuladen. Es unterstützt die vollständige Sicherung und stellt die Verschlüsselung von Mongodump wieder her. Wenn Sie sehen möchten, wie es funktioniert, finden Sie auf unserer Website eine Demo.
Wiederherstellen von MongoDB aus einer Sicherung
Es gibt grundsätzlich zwei Möglichkeiten, einen Dump im BSON-Format zu verwenden:
- Mongod direkt aus dem Backup-Verzeichnis ausführen
- Mongorestore ausführen und Sicherung wiederherstellen
Mongod direkt aus einem Backup ausführen
Eine Voraussetzung für das Ausführen von mongod direkt aus dem Backup ist, dass das Backup-Ziel ein Standard-Dump ist und nicht gzippt ist.
Der MongoDB-Daemon überprüft dann die Integrität des Datenverzeichnisses, fügt die Verwaltungsdatenbank, Journale, Sammlungs- und Indexkataloge und einige andere Dateien hinzu, die zum Ausführen von MongoDB erforderlich sind. Wenn Sie zuvor WiredTiger als Speicher-Engine ausgeführt haben, werden die vorhandenen Sammlungen jetzt als MMAP ausgeführt. Für einfache Datendumps oder Integritätsprüfungen funktioniert dies gut.
mongorestore läuft
Ein besserer Weg zur Wiederherstellung wäre offensichtlich die Wiederherstellung des Knotens mit einem Mongorestore.
mongorestore dump/Dadurch wird die Sicherung in den Standardservereinstellungen (localhost, Port 27017) wiederhergestellt und alle Datenbanken in der Sicherung, die sich auf diesem Server befinden, überschrieben. Jetzt gibt es unzählige Parameter, um den Wiederherstellungsprozess zu manipulieren, und wir werden einige der wichtigen behandeln.
In ClusterControl geschieht dies in der Option Backup wiederherstellen. Sie können die Maschine auswählen, auf der das Backup wiederhergestellt wird, und den Rest erledigen. Dies schließt verschlüsselte Sicherungen ein, bei denen Sie normalerweise auch Ihre Sicherung entschlüsseln müssten.
Objektvalidierung
Da die Sicherung BSON-Daten enthält, würden Sie erwarten, dass der Inhalt der Sicherung korrekt ist. Es könnte jedoch sein, dass das abgelegte Dokument zunächst fehlerhaft formatiert war. Mongodump überprüft nicht die Integrität der Daten, die es ausgibt.
Um dieser Verwendung zu begegnen - objcheck, das mongorestore dazu zwingt, alle Anfragen von Clients nach Erhalt zu validieren, um sicherzustellen, dass Clients niemals ungültige Dokumente in die Datenbank einfügen. Dies kann sich geringfügig auf die Leistung auswirken.
Oplog-Wiedergabe
Oplog zu Ihrem Backup ermöglicht es Ihnen, ein konsistentes Backup durchzuführen und eine Point-in-Time-Wiederherstellung durchzuführen. Aktivieren Sie den oplogReplay-Parameter, um das oplog während des Wiederherstellungsprozesses anzuwenden. Um zu steuern, wie weit das Oplog wiedergegeben wird, können Sie einen Zeitstempel im oplogLimit-Parameter definieren. Nur Transaktionen bis zum Zeitstempel werden dann angewendet.
Wiederherstellen eines vollständigen ReplicaSets aus einer Sicherung
Die Wiederherstellung eines replicaSets unterscheidet sich nicht wesentlich von der Wiederherstellung eines einzelnen Knotens. Entweder müssen Sie zuerst das replicaSet einrichten und direkt in das replicaSet wiederherstellen. Oder Sie stellen zuerst einen einzelnen Knoten wieder her und verwenden dann diesen wiederhergestellten Knoten, um ein Replikatset zu erstellen.
Node zuerst wiederherstellen, dann Replikatset erstellen
Nun synchronisieren der zweite und der dritte Knoten ihre Daten vom ersten Knoten. Nachdem die Synchronisierung abgeschlossen ist, wurde unser replicaSet wiederhergestellt.
Zuerst ein ReplicaSet erstellen, dann wiederherstellen
Im Gegensatz zum vorherigen Prozess können Sie zuerst das replicaSet erstellen. Konfigurieren Sie zuerst alle drei Hosts mit aktiviertem replicaSet, starten Sie alle drei Daemons und initiieren Sie das replicaSet auf dem ersten Knoten:
Nun, da wir das replicaSet erstellt haben, können wir unser Backup direkt darin wiederherstellen:
Unserer Meinung nach ist das Restaurieren eines Replika-Sets auf diese Weise viel eleganter. Es ist näher an der Art und Weise, wie Sie normalerweise ein neues Replikatset von Grund auf neu einrichten und es dann mit (Produktions-)Daten füllen würden.
Einen neuen Knoten in ein ReplicaSet setzen
Beim Scale-out eines Clusters durch Hinzufügen eines neuen Knotens in MongoDB muss die anfängliche Synchronisierung des Datensatzes erfolgen. Mit der MySQL-Replikation und Galera sind wir es so gewohnt, ein Backup zu verwenden, um die anfängliche Synchronisierung zu starten. Mit MongoDB ist dies möglich, aber nur durch das Erstellen einer binären Kopie des Datenverzeichnisses. Wenn Sie nicht über die Mittel verfügen, um einen Dateisystem-Snapshot zu erstellen, müssen Sie mit Ausfallzeiten auf einem der vorhandenen Knoten rechnen. Der Prozess mit Ausfallzeiten wird unten beschrieben.
Seeding mit einem Backup
Was würde also passieren, wenn Sie den neuen Knoten stattdessen aus einem Mongodump-Backup wiederherstellen und ihn dann einem replicaSet beitreten lassen? Die Wiederherstellung aus einer Sicherung sollte theoretisch denselben Datensatz ergeben. Da dieser neue Knoten aus einer Sicherung wiederhergestellt wurde, fehlt ihm die replicaSetId und MongoDB wird dies bemerken. Da MongoDB diesen Knoten nicht als Teil des replicaSets sieht, löst der Befehl rs.add() dann immer die anfängliche Synchronisierung von MongoDB aus. Die anfängliche Synchronisierung löst immer das Löschen aller vorhandenen Daten auf dem MongoDB-Knoten aus.
Die replicaSetId wird beim Initiieren eines replicaSets generiert und kann leider nicht manuell gesetzt werden. Das ist schade, da die Wiederherstellung von einem Backup (einschließlich der Wiederholung des Oplogs) uns theoretisch einen 100 % identischen Datensatz liefern würde. Es wäre schön, wenn die anfängliche Synchronisierung in MongoDB optional wäre, um diesen Anwendungsfall zu erfüllen.
