Datenbanksysteme haben die Aufgabe, relevante Daten jederzeit im Betrieb zu speichern und konsistent verfügbar zu machen. Die meisten Unternehmen können ihre Geschäfte nach Fällen von Datenverlusten aufgrund eines Datenbankausfalls, einer Sicherheitsbrücke, menschlicher Fehler oder eines katastrophalen Ausfalls, der die Betriebsknoten in der Produktion vollständig zerstören kann, nicht fortsetzen. Die Aufbewahrung von Datenbanken im selben Rechenzentrum birgt ein hohes Risiko, im Falle dieser Ausschreitungen alle Daten zu verlieren.
Replikation und Backup sind die häufig verwendeten Methoden, um eine hohe Verfügbarkeit von Daten sicherzustellen. Die Auswahl zwischen den beiden hängt davon ab, wie häufig sich die Daten ändern. Die Sicherung wird am besten dort bevorzugt, wo sich die Daten nicht häufiger ändern und Sie nicht erwarten, so viele Sicherungsdateien zu haben. Auf der anderen Seite wird die Replikation für sich häufig ändernde Daten bevorzugt, abgesehen von einigen anderen Vorteilen, die damit verbunden sind, wie z. B. das Bereitstellen von Daten an einem bestimmten Ort durch Verringern der Latenz von Anforderungen. Sowohl die Replikation als auch die Sicherung können jedoch für maximale Datenintegrität und -konsistenz während der Wiederherstellung in jedem Fall eines Fehlers verwendet werden.
Datenbanksicherungen bieten neben der Bereitstellung eines Wiederherstellungspunkts weitere Vorteile, da sie Grundlagen für die Erstellung neuer Umgebungen für Entwicklung, offenen Zugriff und Staging bereitstellen, ohne die Produktion zu beeinträchtigen. Das Entwicklungsteam kann neu integrierte Funktionen schnell und einfach testen und deren Entwicklung beschleunigen. Backups können auch zum Checkpoint für Codefehler verwendet werden, wenn die resultierenden Daten nicht konsistent sind.
Überlegungen zum Sichern von MongoDB
Backups werden an bestimmten Punkten erstellt, um wiederzugeben (als Momentaufnahme der Datenbank), welche Daten die Datenbank zu diesem bestimmten Zeitpunkt hostet. Wenn die Datenbank an einem bestimmten Punkt ausfällt, können wir die letzte Sicherungsdatei verwenden, um die DB auf einen Punkt vor dem Ausfall zurückzusetzen. Man muss jedoch einige Faktoren berücksichtigen, bevor man eine Wiederherstellung durchführt, und dazu gehören:
- Wiederherstellungspunktziel
- Ziel der Erholungszeit
- Datenbank- und Snapshot-Isolierung
- Komplikationen beim Sharding
- Wiederherstellungsprozess
- Leistungsfaktoren und verfügbarer Speicherplatz
- Flexibilität
- Komplexität der Bereitstellung
Wiederherstellungspunktziel
Dies wird durchgeführt, um festzustellen, wie viele Daten Sie während des Sicherungs- und Wiederherstellungsprozesses zu verlieren bereit sind. Wenn wir beispielsweise Benutzerdaten und Clickstream-Daten haben, haben Benutzerdaten Vorrang vor der Clickstream-Analyse, da letztere nach der Wiederherstellung durch Überwachungsvorgänge in Ihrer Anwendung neu generiert werden können. Für kritische Daten wie Bankinformationen, Produktionsindustriedaten und Informationen zu Kommunikationssystemen sollte eine kontinuierliche Sicherung bevorzugt und in engen Abständen durchgeführt werden. Wenn sich die Daten nicht häufig ändern, ist es möglicherweise weniger kostspielig, viele davon zu verlieren, wenn Sie einen wiederhergestellten Snapshot von beispielsweise 6 Monaten oder 1 Jahr früher erstellen.
Ziel der Erholungszeit
Dies dient der Analyse und Bestimmung, wie schnell der Wiederherstellungsvorgang durchgeführt werden kann. Während der Wiederherstellung kommt es bei Ihren Anwendungen zu einer gewissen Ausfallzeit, die auch direkt proportional zur wiederherzustellenden Datenmenge ist. Wenn Sie einen großen Datensatz wiederherstellen, dauert dies länger.
Datenbank- und Snapshot-Isolierung
Isolation ist ein Maß dafür, wie nah Backup-Snapshots von den primären Datenbankservern in Bezug auf logische Konfiguration und physisch sind. Wenn sie nahe genug sind, verkürzt sich die Wiederherstellungszeit auf Kosten einer erhöhten Wahrscheinlichkeit, dass sie gleichzeitig mit der Datenbank zerstört werden. Es ist nicht ratsam, Backups und die Produktionsumgebung im selben System zu hosten, um zu vermeiden, dass sich Unterbrechungen auf den Servern auch auf die Backups auswirken.
Komplikationen beim Sharding
Für ein verteiltes Datenbanksystem durch Sharding wird eine gewisse Backup-Komplexität dargestellt und Schreibaktivitäten müssen möglicherweise im gesamten System angehalten werden. Unterschiedliche Shards werden unterschiedliche Arten von Backups zu unterschiedlichen Zeiten abschließen. Betrachten Sie logische Backups und Snapshot-Backups,
Logische Backups
- Shards haben unterschiedliche Größen und enden daher zu unterschiedlichen Zeiten
- MongoDB-Basis-Dumps ignorieren --oplog und sind daher nicht bei jedem Shard konsistent.
- Der Balancer könnte ausgeschaltet sein, obwohl er eingeschaltet sein sollte, nur weil einige Shards den Wiederherstellungsprozess möglicherweise nicht abgeschlossen haben
Snapshot-Sicherungen
- Funktioniert gut für ein einzelnes Replikat der Versionen 3.2 und höher. Sie sollten daher erwägen, Ihre MongoDB-Version zu aktualisieren.
Wiederherstellungsprozess
Manche Leute führen Backups durch, ohne zu testen, ob sie im Falle einer Wiederherstellung funktionieren. Ein Backup soll im Wesentlichen eine Wiederherstellungsfähigkeit bereitstellen, da es sonst unbrauchbar wird. Sie sollten immer versuchen, die Sicherungen auf verschiedenen Testservern auszuführen, um zu sehen, ob sie funktionieren.
Leistungsfaktoren und verfügbarer Speicherplatz
Backups nehmen auch viele Größen an, da die Daten aus der Datenbank selbst und ausreichend komprimiert werden müssen, um nicht viel unnötigen Speicherplatz zu belegen, der die gesamten Speicherressourcen des Systems beschneiden könnte. Sie können in ZIP-Dateien archiviert werden, wodurch ihre Gesamtgröße reduziert wird. Außerdem kann man, wie bereits erwähnt, die Backups in verschiedenen Rechenzentren aus der Datenbank selbst archivieren.
Backups können unterschiedliche Leistungen der Datenbank bestimmen, da einige sie beeinträchtigen könnten. In diesem Fall führen kontinuierliche Sicherungen zu Rückschlägen und sollten daher in geplante Sicherungen umgewandelt werden, um eine Erschöpfung der Wartungsfenster zu vermeiden. In den meisten Fällen werden sekundäre Server bereitgestellt, um Backups zu unterstützen. In diesem Fall:
- Einzelne Knoten können nicht konsistent gesichert werden, da MongoDB read-uncommitted ohne oplog verwendet, wenn der mongodump-Befehl verwendet wird und in diesem Fall Sicherungen nicht sicher sind.
- Verwenden Sie sekundäre Knoten für Sicherungen, da der Vorgang selbst je nach Datenmenge Zeit in Anspruch nimmt und die verbundenen Anwendungen einige Ausfallzeiten verursachen. Wenn Sie die primäre verwenden, die auch die Oplogs aktualisieren muss, können während dieser Ausfallzeit einige Daten verloren gehen
- Der Wiederherstellungsprozess nimmt viel Zeit in Anspruch, aber die zugewiesenen Speicherressourcen sind winzig.
Flexibilität
Manchmal möchten Sie möglicherweise einige der Daten während der Sicherung nicht, wie im Beispiel des Wiederherstellungspunktziels, man möchte vielleicht, dass die Wiederherstellung durchgeführt wird und die Daten der Benutzerklicks herausgefiltert werden. Dazu benötigen Sie eine partielle Backup-Strategie, die die Flexibilität bietet, die Daten herauszufiltern, an denen Sie nicht interessiert sind, und somit die Wiederherstellungsdauer und Ressourcen zu reduzieren, die verschwendet worden wären. Eine inkrementelle Sicherung kann auch nützlich sein, damit nur geänderte Datenteile vom letzten Snapshot gesichert werden, anstatt für jeden Snapshot vollständige Sicherungen zu erstellen.
Komplexität der Bereitstellung
Ihre Sicherungsstrategie sollte im Laufe der Zeit einfach einzurichten und zu warten sein. Sie können Ihre Sicherungen auch so planen, dass Sie sie nicht jederzeit manuell durchführen müssen.
Fazit
Datenbanksysteme garantieren ein „Leben nach dem Tod“, wenn nur ein gut etabliertes Sicherungssystem vorhanden ist. Die Datenbank könnte durch katastrophale Faktoren, menschliches Versagen oder Sicherheitsangriffe zerstört werden, die zu Datenverlust oder -beschädigung führen können. Vor der Durchführung eines Backups muss man die Art der Daten in Bezug auf Größe und Wichtigkeit berücksichtigen. Es ist immer nicht ratsam, Ihre Backups im selben Rechenzentrum wie Ihre Datenbank aufzubewahren, um die Wahrscheinlichkeit zu verringern, dass die Backups gleichzeitig zerstört werden. Sicherungen können die Leistung der Datenbank beeinträchtigen, daher sollte man vorsichtig sein, welche Strategie man verwendet und wann man die Sicherung durchführt. Führen Sie Ihre Sicherungen nicht auf dem primären Knoten durch, da dies zu Systemausfällen während der Sicherung und damit zum Verlust wichtiger Daten führen kann.
