NetVault Plug-in for MySQL 12.2 - Benutzerhandbuch

Szenarien für die Wiederherstellung von vollständigen und differenziellen Backups

Der DBA hat eine Sicherungsrichtlinie eingerichtet, in der Vollsicherungen jeden Sonntag um 23:00 Uhr und differenzielle Sicherungen Montag bis Samstag um 23:00 Uhr durchgeführt werden. Da der DBA differenzielle Sicherungen durchführt, werden die Binärprotokolle nach jeder dieser Art von Sicherung aufbewahrt, wodurch die Sicherung mehr Zeit in Anspruch nimmt, aber eine schnellere Wiederherstellung ermöglicht.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich irgendwann am Donnerstagvormittag vor der Ankunft des DBA am Arbeitsplatz gelöscht hat.

Der DBA beschließt, bis zum Zeitpunkt der letzten differenziellen Sicherung eine vollständige Wiederherstellung durchzuführen – die Sicherung, die am Mittwochabend durchgeführt wurde.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

In den folgenden Beispielen ist ein Szenario mit vollständigen und differenziellen Sicherungen vorhanden und der DBA möchte Daten bis zu einem bestimmten Zeitpunkt wiederherstellen.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Mittwoch um 20:00 Uhr gelöscht hat.

Der DBA muss eine Wiederherstellung durchführen, bei der die Datenbank bis zum Zeitpunkt kurz vor der Löschung der Tabelle am Mittwoch um 20:00 Uhr wiederhergestellt wird. Daher werden die folgenden Phasen durchgeführt:

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Mittwoch um 20:00 Uhr gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor Ausgabe des Befehls „Tabelle löschen“ um 20:00 Uhr durchzuführen. Der DBA möchte auch die Transaktionen, die in den verbleibenden Tabellen stattgefunden haben, ab dem Zeitpunkt nach Löschung der Reihenfolgetabelle und bis zum Ende der gesicherten Binärprotokolle wiederherstellen. Diese Entscheidung stellt sicher, dass neben der Wiederherstellung der gelöschten Tabelle so viele Transaktionen wie möglich wiederhergestellt wurden. Daher werden die folgenden Phasen durchgeführt:

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Donnerstag um 06:00 Uhr gelöscht hat.

Der DBA muss eine Wiederherstellung durchführen, bei der die Datenbank bis zum Zeitpunkt kurz vor der Löschung der Tabelle am Donnerstag um 06:00 Uhr wiederhergestellt wird.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Donnerstag um 06:00 Uhr gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Der DBA möchte auch die Transaktionen, die in den verbleibenden Tabellen stattgefunden haben, ab dem Zeitpunkt nach der Löschung der Reihenfolgetabelle und bis zum Ende der aktuellen Binärprotokolle wiederherstellen. Diese Entscheidung stellt sicher, dass neben der Wiederherstellung der gelöschten Tabelle so viele Transaktionen wie möglich wiederhergestellt wurden. Daher werden die folgenden Phasen durchgeführt:

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

In den folgenden Beispielen ist ein Szenario mit vollständigen und inkrementellen Sicherungen vorhanden und der DBA möchte Daten bis zu einem bestimmten Zeitpunkt wiederherstellen, aber eine definitivere Methode für die Zeitpunktdefinition verwenden. Dieser Vorgang erfolgt unter Verwendung identifizierter „Positionswerte“, die in den MySQL-Binärprotokollen vorhanden sind.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Mittwoch um 20:00 Uhr gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Darüber hinaus wünscht der DBA eine präzisere Wiederherstellung, daher entscheidet er sich für eine positionsbasierte Wiederherstellung. Dieser Prozess wird in den folgenden Phasen veranschaulicht:

In dieser Phase werden nur die Binärprotokolle, die in der differenziellen Sicherung am Mittwochabend aufgezeichnet wurden, an einem temporären Speicherort wiederhergestellt. Mit diesem Prozess kann der DBA die Position im Protokoll ermitteln, die angibt, wann die Reihenfolgetabelle gelöscht wurde.

Verwenden Sie das mysqlbinlog-Hilfsprogramm für die wiederhergestellten Binärprotokolle: Dieser Schritt wird außerhalb von NetVault Backup ausgeführt, um die Position des Befehls „Tabelle löschen“ zu identifizieren, die der DBA nicht wiederherstellen möchte. (Informationen zu diesem Hilfsprogramm und diesem Prozess finden Sie im MySQL-Referenzhandbuch.) Bei diesem Prozess identifizierte der DBA den Befehl „Tabelle löschen“ als Protokollposition 805 im Binärprotokoll MYSQLSVR-bin.000009, das am temporären Speicherort auf dem MySQL-Server wiederhergestellt wurde, und beide Werte wurden notiert.

Nachdem die Position aus dem wiederhergestellten Binärprotokoll identifiziert wurde, wird eine PIT-Wiederherstellung mit der differenziellen Sicherung von Mittwoch durchgeführt.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Mittwoch um 20:00 Uhr gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Der DBA möchte auch die Transaktionen, die in den verbleibenden Tabellen stattgefunden haben, ab dem Zeitpunkt nach der Löschung der Reihenfolgetabelle und bis zum Ende der gesicherten Binärprotokolle wiederherstellen. Darüber hinaus wünscht der DBA eine präzisere Wiederherstellung, daher entscheidet er sich für eine positionsbasierte Wiederherstellung. Dieser Prozess wird in den folgenden Phasen veranschaulicht:

In dieser Phase werden nur die Binärprotokolle, die in der inkrementellen Sicherung am Mittwochabend aufgezeichnet wurden, an einem temporären Speicherort wiederhergestellt. Mit diesem Prozess kann der DBA die Position im Protokoll ermitteln, die angibt, wann die Reihenfolgetabelle gelöscht wurde.

Verwenden Sie das mysqlbinlog-Hilfsprogramm für die wiederhergestellten Binärprotokolle: Dieser Schritt wird außerhalb von NetVault Backup ausgeführt, um die Position des Befehls „Tabelle löschen“ zu identifizieren, die der DBA nicht wiederherstellen möchte. (Informationen zu diesem Hilfsprogramm und diesem Prozess finden Sie im MySQL-Referenzhandbuch.) Bei diesem Prozess identifizierte der DBA den Befehl „Tabelle löschen“ als Protokollposition 805 im Binärprotokoll MYSQLSVR-bin.000009, das am temporären Speicherort auf dem MySQL-Server wiederhergestellt wurde, und beide Werte wurden notiert.

Nachdem die Position aus den wiederhergestellten Binärprotokollen identifiziert wurde, wird die PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

WICHTIG: Die End- und Startpositionen müssen tatsächliche Positionen sein, die in einem Binärprotokoll aufgeführt sind, nicht willkürliche Zahlen, die größer als die Position der unerwünschten Transaktion sind.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Donnerstag um 06:00 Uhr gelöscht hat.

Der DBA muss eine Wiederherstellung durchführen, bei der die Datenbank bis zum Zeitpunkt kurz vor der Löschung der Tabelle am Donnerstag um 06:00 Uhr wiederhergestellt wird. Darüber hinaus wünscht der DBA eine präzisere Wiederherstellung, daher entscheidet er sich für eine positionsbasierte Wiederherstellung. Dieser Prozess wird in den folgenden Phasen veranschaulicht:

Verwenden Sie das mysqlbinlog-Hilfsprogramm für die aktuellen Binärprotokolle: Dieser Schritt wird außerhalb von NetVault Backup ausgeführt, um die Position des Befehls „Tabelle löschen“ zu identifizieren, die der DBA nicht wiederherstellen möchte. (Informationen zu diesem Hilfsprogramm und diesem Prozess finden Sie im MySQL-Referenzhandbuch.) Bei diesem Prozess identifizierte der DBA den Befehl „Tabelle löschen“ als Protokollposition 805 im aktuellen Binärprotokoll MYSQLSVR-bin.000009.

Nachdem die Position aus den wiederhergestellten Binärprotokollen identifiziert wurde, wird eine PIT-Wiederherstellung mit der differenziellen Sicherung von Mittwoch durchgeführt.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntagabend. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzern Tabelle nicht gefunden-Fehler auf der Tabelle Reihenfolge angezeigt werden. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, da ein Entwickler sie unwissentlich am Donnerstag um 06:00 Uhr gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Der DBA möchte auch die Transaktionen, die in den verbleibenden Tabellen stattgefunden haben, ab dem Zeitpunkt nach der Löschung der Reihenfolgetabelle und bis zum Ende des aktuellen Binärprotokolls wiederherstellen. Darüber hinaus wünscht der DBA eine präzisere Wiederherstellung, daher entscheidet er sich für eine positionsbasierte Wiederherstellung. Dieser Prozess wird in den folgenden Phasen veranschaulicht:

Verwenden Sie das mysqlbinlog-Hilfsprogramm für die aktuellen Binärprotokolle: Dieser Schritt wird außerhalb von NetVault Backup ausgeführt, um die Position des Befehls „Tabelle löschen“ zu identifizieren, die der DBA nicht wiederherstellen möchte. (Informationen zu diesem Hilfsprogramm und diesem Prozess finden Sie im MySQL-Referenzhandbuch.) Bei diesem Prozess identifizierte der DBA den Befehl „Tabelle löschen“ als Protokollposition 805 im aktuellen Binärprotokoll MYSQLSVR-bin.000009.

Nachdem die Position aus den wiederhergestellten Binärprotokollen identifiziert wurde, wird eine PIT-Wiederherstellung mit der differenziellen Sicherung von Mittwoch durchgeführt.

WICHTIG: Der DBA muss nicht die differenziellen Sicherungen von Montag- und Dienstagabend wiederherstellen. Wenn Sie sich für die Durchführung von differenziellen Sicherungen entscheiden, ist jede abends durchgeführte Sicherung kumulativ, d. h. bis zur Vollsicherung von Sonntag. Das bedeutet, dass die Sicherung von Mittwochabend alle Binärprotokolle umfasst, die am Montag, Dienstag und Mittwoch erstellt wurden – bis zur Vollsicherung von Sonntag.

WICHTIG: Die End- und Startpositionen müssen tatsächliche Positionen sein, die in einem Binärprotokoll aufgeführt sind, nicht willkürliche Zahlen, die größer als die Position der unerwünschten Transaktion sind.

Führen Sie eine PIT-Wiederherstellung durch, wenn das MIXED-Binärprotokollierungsformat verwendet wird und datenbankübergreifende Aktualisierungen ausgegeben werden.

WICHTIG: Wenn an Ihrem Standort das MIXED-Binärprotokollierungsformat verwendet wird und alle Datenbankbenutzer und -programme den Best Practices folgen, um sicherzustellen, dass geänderte Tabellen in der von USE ausgewählten Datenbank enthalten sind und keine datenbankübergreifenden Aktualisierungen veröffentlicht werden, gilt dieses Thema nicht für Ihren Standort. (Weitere Informationen finden Sie unter Verwenden des MIXED-Binärprotokollierungsformats.) Sie können PIT-Wiederherstellungsaufträge ausführen und das Binärprotokoll wird an dem angegebenen Punkt für die im Auftrag ausgewählten Datenbanken wiedergegeben.

Wie bereits erwähnt, werden Transaktionen nicht zum angegebenen Zeitpunkt wiedergegeben, wenn Sie einen PIT-Wiederherstellungsjob ausführen, wenn Benutzer und Programme in Ihrer Umgebung Tabellen in Datenbanken ändern, die nicht von USE ausgewählt wurden und datenbankübergreifende Aktualisierungen ausgeben. Quest empfiehlt daher, dass alle Datenbankbenutzer und -programme sicherstellen, dass geänderte Tabellen in der Datenbank enthalten sind, die von USE ausgewählt wurde, und dass keine datenbankübergreifenden Aktualisierungen ausgegeben werden. Wenn diese Richtlinie für Ihre Umgebung nicht geeignet ist, empfiehlt Quest, dass Sie das MIXED-Binärprotokollierungsformat nicht verwenden.

WICHTIG: Im folgenden Verfahren wird mysqlbinlog ohne die Option --database verwendet. Daher werden alle Inhalte des Binärprotokolls angewendet und alle Datenbanken werden möglicherweise geändert. Ziehen Sie in Betracht, dieses Verfahren auf einen alternativen MySQL-Server anzuwenden und die entsprechenden Daten aus dem alternativen MySQL-Server zu extrahieren. Wenn Sie das folgende Verfahren auf Ihren MySQL-Produktionsserver anwenden, werden alle Datenbanken auf den angegebenen Punkt zurückgesetzt. Wenden Sie das Verfahren nur dann in Ihrer Produktionsumgebung an, wenn Sie alle MySQL-Serverdatenbanken auf den angegebenen Punkt zurücksetzen möchten.

Beispiele für Wiederherstellungsszenarien für MySQL Enterprise Backup

Um eine Wiederherstellung nach einem Fehler oder einer Datenbeschädigung durchzuführen, müssen beim Einrichten des Auftrags verschiedene Einstellungen bezüglich der für die Wiederherstellung ausgewählten Daten und der auf der Registerkarte Optionen verfügbaren Optionen vorgenommen werden.

Szenarien für die Wiederherstellung von ausschließlich Vollsicherungen