Eine Anleitung zum Sichern von Datenbanken

„Oh, kein Unterschlupf kann einem Meteoriteneinschlag standhalten. Aber Sie haben, wie jeder andere auch, eine Reserve, also machen Sie sich keine Sorgen.



Stanislav Lem, "Die Sterntagebücher von Iyon dem Tikhoi"

Sichern bezieht sich auf das Speichern einer Kopie Ihrer Daten außerhalb des primären Speicherorts.







Der Hauptzweck der Sicherung besteht darin, Daten nach ihrem Verlust wiederherzustellen. In diesem Zusammenhang hören wir oft, dass Sie, wenn Sie ein Replikat einer Datenbank haben, jederzeit Daten daraus wiederherstellen können und keine Sicherung benötigen. Mit Backup können Sie mindestens drei Aufgaben lösen, die mit einem Replikat nicht gelöst werden können, und ein Replikat kann ohne Backup nicht initialisiert werden.



Erstens können Sie mit einer Sicherung Daten nach einem logischen Fehler wiederherstellen. Beispielsweise hat ein Buchhalter eine Gruppe von Transaktionen gelöscht oder ein DBA hat einen Tabellenbereich zerstört. Beide Vorgänge sind aus Sicht der Datenbank absolut legitim, und der Replikationsprozess reproduziert sie in der Replikatdatenbank.



Zweitens sind moderne DBMS sehr zuverlässige Softwaresysteme, aber gelegentlich treten Schäden an den internen Strukturen der Datenbank auf, wonach der Zugriff auf die Daten verschwindet. Was besonders anstößig ist, ein solcher Verstoß tritt normalerweise bei hoher Last oder bei der Installation eines Updates auf. Sowohl die hohe Auslastung als auch die regelmäßigen Aktualisierungen zeigen jedoch, dass die Datenbank keineswegs eine Testdatenbank ist und die darin gespeicherten Daten wertvoll sind.



Schließlich klont die dritte Aufgabe, für deren Lösung eine Sicherungskopie erforderlich ist, die Datenbank beispielsweise zu Testzwecken.



Die Datenbanksicherung basiert irgendwie auf einem von zwei Prinzipien:

• Abrufen von Daten mit anschließendem Speichern in einem beliebigen Format;
• Schnappschuss von Datenbankdateien und Speichern von Protokollen.

Schauen wir uns diese Prinzipien und die Werkzeuge, die sie implementieren, genauer an.

Daten hochladen

Die mit einem DBMS gelieferten Dienstprogramme müssen über Tools zum Hoch- und Herunterladen von Daten verfügen. Die Daten werden entweder im Textformat oder in einem für ein bestimmtes DBMS spezifischen Binärformat gespeichert. In der folgenden Tabelle sind solche Tools aufgeführt:





Das Textformat ist gut, da es von externen Programmen bearbeitet oder sogar erstellt werden kann, und das Binärformat wiederum ist gut, da Sie Daten aufgrund des parallelen Ladens und Speicherns von Ressourcen bei der Formatkonvertierung schnell entladen und laden können.



Trotz der Einfachheit und Offensichtlichkeit der Idee, Daten zu entladen, wird diese Methode selten zum Sichern geladener Industriedatenbanken verwendet. Hier sind die Gründe, warum das Auslagern für eine vollständige Sicherung nicht geeignet ist:

• Der Entladevorgang führt zu einer erheblichen Belastung des Quellsystems.
• Das Entladen nimmt viel Zeit in Anspruch - bis das Entladen abgeschlossen ist, wird es irrelevant.
• Es ist fast unmöglich, die gesamte Datenbank unter hoher Last konsistent zu entladen, da das DBMS gezwungen ist, zum Zeitpunkt des Entladens einen Snapshot seines Status zu erstellen. Je mehr Transaktionen seit Beginn des Uploads festgeschrieben wurden, desto größer ist das Snapshot-Volumen (irrelevante Kopien von Daten in PostgreSQL, Rückgängigmachen des Speicherplatzes in Oracle, Tempdb in Microsoft SQL Server usw.).
• Beim Entladen bleibt die logische Struktur der Daten erhalten, ihre physische Struktur bleibt jedoch nicht erhalten - Parameter für die physische Speicherung von Tabellen, Indizes usw.; Das Neuerstellen von Indizes beim Booten kann lange dauern.

Trotzdem hat das Entladen Vorteile:

• hohe Selektivität: Sie können einzelne Tabellen, einzelne Felder und sogar einzelne Zeilen entladen;
• Die hochgeladenen Daten können in eine Datenbank einer anderen Version geladen werden. Wenn der Upload im Textformat erfolgt, in eine andere Datenbank.

Daher wird das Entladen hauptsächlich für Aufgaben wie das Sichern kleiner Tabellen (z. B. Verzeichnisse) oder das Verteilen von Datasets mit der nächsten Version der Anwendung verwendet.



Die häufigste Methode zum Sichern von Datenbanken ist das Kopieren von Datenbankdateien.

"Kaltes" Speichern von Datenbankdateien

Die naheliegende Idee ist, die Datenbank anzuhalten und alle Dateien zu kopieren. Dies wird als Cold Backup bezeichnet. Die Methode ist äußerst zuverlässig und einfach, weist jedoch zwei offensichtliche Nachteile auf:

• Bei einer kalten Sicherung können Sie nur den Status der Datenbank wiederherstellen, der sich zum Zeitpunkt des Herunterfahrens befand. Transaktionen, die nach dem Neustart der Datenbank durchgeführt wurden, werden nicht in die "kalte" Sicherung einbezogen.
• Nicht jede Datenbank hat ein technologisches Fenster, in dem die Datenbank gestoppt werden kann.

Wenn Sie mit kalten Backups zufrieden sind, denken Sie daran

• «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
• , . , «» .

«»

Die meisten modernen Datenbanksicherungen werden durch Kopieren der Datenbankdateien durchgeführt, ohne die Datenbank anzuhalten. Hier sind mehrere Probleme sichtbar:

• Zu Beginn des Kopiervorgangs stimmt der Inhalt der Datenbank möglicherweise nicht mit dem Inhalt der Dateien überein, da sich einige Informationen im Cache befinden und noch nicht auf die Festplatte geschrieben wurden.
• Während des Kopierens kann sich der Inhalt der Datenbank ändern. Wenn veränderbare Datenstrukturen verwendet werden, ändert sich der Inhalt der Dateien, und wenn unveränderliche Strukturen verwendet werden, ändert sich der Dateisatz: Neue Dateien werden angezeigt und alte werden gelöscht.
• Da das Schreiben von Daten in die Datenbank und das Lesen von Datenbankdateien in keiner Weise synchronisiert werden, liest das Sicherungsprogramm möglicherweise eine falsche Seite, wobei die Hälfte aus der alten Version der Seite und die andere Hälfte aus der neuen stammt.

Damit die Sicherung konsistent ist, verfügt jedes DBMS über einen Befehl, der darüber informiert, dass der Sicherungsprozess begonnen hat. Syntaktisch kann dieser Befehl anders aussehen:

• in Oracle ist es ein separater Befehl ALTER DATABASE / TABLESPACE BEGIN BACKUP;
• in PostgreSQL die Funktion pg_start_backup ();
• Unter Microsoft SQL Server und DB2 ist die Vorbereitung einer Sicherung während des Befehls BACKUP DATABASE implizit.
• In MySQL Enterprise, Percoba Server, Cassandra und MongoDB wird die Vorbereitung implizit von einem externen Dienstprogramm durchgeführt - mysqlbackup, Percona XtraBackup, OpsCenter bzw. Ops Manager.

Trotz der syntaktischen Unterschiede sieht der Prozess der Vorbereitung einer Sicherung gleich aus.



So sieht die Vorbereitung von Sicherungen in einem DBMS mit variablen Festplattenstrukturen aus, dh in allen herkömmlichen relationalen Festplattensystemen:

1. Der Moment des Starts der Sicherung wird gespeichert. Die Sicherung muss von nun an die Datenbankprotokolle enthalten.
2. Es wird ein Prüfpunkt durchgeführt, dh alle Änderungen, die bis zu diesem Zeitpunkt auf den Datenseiten vorgenommen wurden, werden auf die Festplatte übertragen. Dadurch wird sichergestellt, dass vor dem Start der Sicherung während der Wiederherstellung keine Protokolle erforderlich sind.
3. : , , , . , . , . , , .
4. , , . , , .

Nachdem alle oben genannten Verfahren abgeschlossen sind, können Sie die Datendateien mit den Betriebssystem-Tools cp, rsync und anderen kopieren. Das Aktivieren des Sicherungsmodus verringert die Leistung der Datenbank: Erstens erhöht sich das Protokollvolumen, und zweitens dauert die Wiederherstellung länger, wenn der Sicherungsmodus plötzlich fehlschlägt, da die Header der Datendateien nicht aktualisiert werden. Je schneller die Sicherung abgeschlossen ist, desto besser für die Datenbank. Daher sollten Tools wie ein Snapshot des Dateisystems oder ein Mirror Break (BCV) in einem Festplattenarray verwendet werden. Einige DBMS (Oracle, PostgreSQL) bieten dem Administrator die Möglichkeit, die Kopiermethode unabhängig auszuwählen.Andere (Microsoft SQL Server) bieten eine Schnittstelle zur Integration nativer Sicherungsdienstprogramme in Dateisysteme oder Speicher-Engines.



Wenn die Sicherung abgeschlossen ist, müssen Sie die Datenbank wieder in den normalen Zustand versetzen. In Oracle erfolgt dies mit dem Befehl ALTER DATABASE / TABLESPACE END BACKUP, in PostgreSQL durch Aufrufen der Funktion pg_stop_backup () und in anderen Datenbanken durch interne Routinen der entsprechenden Befehle oder externen Dienste.



So sieht die Zeitleiste für den Sicherungsprozess aus:

• Die Vorbereitung für das Backup (Backup starten) nimmt Zeit in Anspruch, manchmal beträchtlich. Selbst wenn gespiegelte Volumes oder Snapshot-Dateisysteme verwendet werden, erfolgt der Sicherungsprozess nicht sofort.
• Zusammen mit den Datendateien müssen die Protokolle ab dem Zeitpunkt gespeichert werden, an dem die Vorbereitung für die Sicherung begann und mit dem Zeitpunkt endet, an dem die Datenbank in ihren normalen Zustand zurückkehrt.
• Sie können diese Sicherung zu dem Zeitpunkt wiederherstellen, zu dem die Datenbank in ihren normalen Zustand zurückkehrt . Eine Wiederherstellung zu einem früheren Zeitpunkt ist nicht möglich.

Bei Datenbanken mit unveränderlichen Datenstrukturen (Snapshots, LSM-Bäume) ist die Situation einfacher. Die Vorbereitung für die Sicherung besteht aus den folgenden Schritten:

1. Daten aus dem Speicher werden auf die Festplatte geschrieben.
2. Die Liste der in der Sicherung enthaltenen Dateien wird aufgezeichnet. Bis der Sicherungsvorgang abgeschlossen ist, darf die Datenbank diese Dateien nicht löschen, auch wenn sie nicht mehr benötigt werden.

Bei einem Signal über das Ende der Sicherung kann eine Datenbank mit unveränderlichen Strukturen wieder unnötige Dateien löschen.

Punktwiederherstellung

Mit der Sicherung können Sie den Status der Datenbank bis zu dem Zeitpunkt wiederherstellen, an dem der Befehl zum Zurückkehren aus dem Sicherungsmodus abgeschlossen ist. Eine Katastrophe, die eine Wiederherstellung erfordert, kann jedoch jederzeit auftreten. Die Aufgabe, den Status der Datenbank auf einen beliebigen Zeitpunkt wiederherzustellen, wird als Wiederherstellung zu einem bestimmten Zeitpunkt bezeichnet.



Zu diesem Zweck sollten Sie die Datenbankprotokolle ab dem Zeitpunkt des Abschlusses der Sicherung speichern und die Protokolle während des Wiederherstellungsvorgangs weiterhin auf die wiederhergestellte Kopie anwenden. Nachdem die Datenbank am Ende der Kopie von einer Sicherungskopie wiederhergestellt wurde, ist der Status der Datenbank (Dateien und zwischengespeicherte Seiten) garantiert korrekt, sodass kein spezieller Protokollierungsmodus erforderlich ist. Durch Anwenden der Protokolle bis zum gewünschten Zeitpunkt können Sie den Status der Datenbank jederzeit abrufen.



Wenn die Geschwindigkeit beim Wiederherstellen einer Sicherung nur durch die Festplattenbandbreite begrenzt ist, wird die Geschwindigkeit beim Anwenden der Protokolle normalerweise durch die Leistung des Prozessors begrenzt. Wenn Änderungen in der Hauptdatenbank parallel auftreten, werden während der Wiederherstellung alle Änderungen nacheinander ausgeführt - in der Reihenfolge, in der sie aus dem Protokoll gelesen wurden. Daher hängt die Wiederherstellungszeit linear davon ab, wie weit der Wiederherstellungspunkt vom Endpunkt der Sicherung entfernt ist. Aus diesem Grund müssen Sie häufig vollständige Sicherungen durchführen - mindestens einmal pro Woche für Datenbanken mit geringer Transaktionslast und vor dem täglichen Kopieren hoch geladener Datenbanken.

Inkrementelle Backups

Um die Punkt-zu-Punkt-Wiederherstellung zu beschleunigen, möchte ich so oft wie möglich sichern können, aber gleichzeitig keinen zusätzlichen Speicherplatz beanspruchen und die Datenbank nicht mit Sicherungsaufgaben belasten.



Die Lösung des Problems ist eine inkrementelle Sicherung, dh es werden nur die Datenseiten kopiert, die sich seit der vorherigen Sicherung geändert haben.

Inkrementelle Sicherungen sind nur für DBMS sinnvoll, die veränderbare Datenstrukturen verwenden.



Das Inkrement kann sowohl aus der vollständigen Sicherung (kumulative Kopie) als auch aus jeder vorherigen Kopie (differenzielle Kopie) berechnet werden.







Leider gibt es keine einheitliche Terminologie und verschiedene Hersteller verwenden unterschiedliche Begriffe:





Bei inkrementellen Sicherungen sieht der Punkt-zu-Punkt-Wiederherstellungsprozess folgendermaßen aus:

• Die letzte vollständige Sicherung, die vor der Wiederherstellung der Wiederherstellung durchgeführt wurde.
• Inkrementelle Kopien werden über die vollständige Kopie wiederhergestellt.
• rollt Protokolle von dem Punkt, an dem die Sicherung gestartet wurde, bis zum Punkt der Wiederherstellung.

Eine kumulative Kopie beschleunigt den Wiederherstellungsprozess. Um beispielsweise den Basiszustand auf einen Punkt zwischen T3 und T4 wiederherzustellen, müssen Sie zwei inkrementelle Kopien und einen Punkt nach T4 wiederherstellen - nur eine.

Offensichtlich ist das Volumen einer kumulativen Kopie geringer als das Volumen mehrerer differenzieller Kopien, da sich einige Seiten mehrmals geändert haben und jede inkrementelle Kopie eine eigene Version der Seite enthält.



Es gibt drei Möglichkeiten, eine inkrementelle Kopie zu erstellen:

1. Erstellen einer vollständigen Kopie und Berechnen der Differenz zur vorherigen vollständigen Kopie;
2. Parsen von Protokollen, Erstellen einer Liste geänderter Seiten und Sichern der in der Liste enthaltenen Seiten;
3. Anforderung geänderter Seiten in der Datenbank.

Die erste Methode spart Speicherplatz, löst jedoch nicht das Problem der Reduzierung der Datenbanklast. Wenn wir eine vollständige Sicherung haben, ist es außerdem sinnlos, sie in eine inkrementelle Sicherung umzuwandeln, da die Wiederherstellung einer vollständigen Sicherung schneller ist als die Wiederherstellung einer vorherigen vollständigen Kopie und eines Inkrements. Mit diesem Ansatz ist es besser, die Aufgabe, Speicherplatz zu sparen, auf spezielle Komponenten mit integrierten Deduplizierungsmechanismen zu verlagern. Dies können entweder spezielle Speichersysteme (EMC DataDomain, HPE StorageWorks VLS, die gesamte NetApp-Linie) oder Softwareprodukte (ZFS, Veritas NetBackup PureFile, Windows Server-Datendeduplizierung) sein.



Die zweite und dritte Methode unterscheiden sich im Mechanismus zum Bestimmen der Liste der geänderten Seiten. Das Parsen von Protokollen ist ressourcenintensiver. Außerdem müssen Sie die Struktur der Protokolldateien kennen, um sie implementieren zu können. Es ist am einfachsten, die Datenbank selbst zu fragen, welche Seiten geändert wurden. Dazu muss der DBMS-Kernel jedoch über die Funktionalität verfügen, die geänderten Blöcke zu verfolgen (Blockänderungsverfolgung).



Inkrementelle Sicherungsfunktionen wurden erstmals mit der Oracle Recovery Manager (RMAN) -Software eingeführt, die mit der Oracle 8i-Version eingeführt wurde. Oracle hat die geänderte Blockverfolgung sofort implementiert, sodass die Protokolle nicht analysiert werden müssen.



PostgreSQL verfolgt keine geänderten Blöcke, daher erkennt das von der russischen Firma Postgres Professional entwickelte Dienstprogramm pg_probackup geänderte Seiten durch Analyse des Protokolls. Das Unternehmen liefert jedoch auch PostgresPro, das eine ptrack-Erweiterung enthält, die Seitenänderungen verfolgt. Bei Verwendung von pg_probackup mit PostgresPro fragt das Dienstprogramm die Datenbank selbst nach geänderten Seiten ab, genau wie RMAN.



Microsoft SQL Server verfolgt wie Oracle geänderte Seiten, aber der Befehl BACKUP ermöglicht nur vollständige und kumulative Sicherungen.



DB2 kann geänderte Seiten verfolgen, ist jedoch standardmäßig deaktiviert. Nach der Aktivierung ermöglicht DB2 vollständige, differenzielle und kumulative Sicherungen.



Ein wichtiger Unterschied zwischen den in diesem Abschnitt beschriebenen Tools (mit Ausnahme von pg_probackup) und den dateibasierten Sicherungstools besteht darin, dass sie die Datenbank nach Seitenbildern abfragen, anstatt die Daten von der Festplatte selbst zu lesen. Der Nachteil dieses Ansatzes ist die geringe zusätzliche Belastung der Basis. Dieser Nachteil wird jedoch durch die Tatsache mehr als ausgeglichen, dass das Lesen der Seite immer korrekt ist, sodass während der Sicherung kein spezieller Journalmodus aktiviert werden muss.



Beachten Sie erneut, dass das Vorhandensein inkrementeller Sicherungen nicht die Anforderung ersetzt, dass Protokolle zu einem beliebigen Zeitpunkt wiederhergestellt werden müssen. Daher werden in Industriedatenbanken Protokolle ständig auf externe Medien umgeschrieben und vollständige und / oder inkrementelle Sicherungen nach einem Zeitplan erstellt.



Die beste Implementierung der Idee der inkrementellen Sicherung ist heute die Zero Data Loss Recovery Appliance (entwickeltes System in Oracle-Terminologie) - eine spezialisierte Oracle-Lösung zum Sichern einer eigenen Datenbank. Der Komplex ist ein Cluster von Servern mit einem großen Festplattenvolumen, auf dem eine modifizierte Version der Recovery Manager-Software installiert ist und sowohl mit anderen Oracle-Software- und Hardwarekomplexen (Database Appliance, Exadata, SPARC Supercluster) als auch mit Oracle-Datenbanken auf herkömmlicher Infrastruktur zusammenarbeiten kann. Im Gegensatz zu "normalem" RMAN implementiert ZDLRA das Konzept "für immer inkrementell". Das System erstellt nur einmal eine vollständige Kopie der Datenbank und erstellt dann nur inkrementelle Kopien. Mit zusätzlichen RMAN-Modulen können Sie Kopien zusammenführen.Erstellen neuer vollständiger Kopien aus inkrementellen.



Es ist ein Verdienst russischer Entwickler, dass pg_probackup auch inkrementelle Kopien kombinieren kann.







Im Gegensatz zu vielen ähnlichen Fragen hat die Frage "Welche Sicherungsmethode ist besser?" Eine eindeutige Antwort. Das Beste ist das native Dienstprogramm für das verwendete DBMS, das die Möglichkeit bietet, inkrementelle Sicherungen durchzuführen.



Für den DBA sind die wichtigsten Themen die Wahl der Sicherungsstrategie und die Integration von Datenbanksicherungen in die Unternehmensinfrastruktur. Diese Fragen gehen jedoch über den Rahmen dieses Artikels hinaus.