NetVault Plug-in for MySQL 12.2 - Benutzerhandbuch

Fertigstellen und Senden des Jobs

Die abschließenden Schritte umfassen die Festlegung zusätzlicher Optionen für Zeitplan, Quelloptionen und erweiterte Optionen, das Weiterleiten des Jobs und die Überwachung des Fortschritts über die Seiten „Jobstatus“ und „Protokolle anzeigen“. Diese Seiten und Optionen sind für alle NetVault Backup-Plug-ins gleich. Weitere Informationen hierzu finden Sie im Quest NetVault Backup Administratorhandbuch.

WICHTIG: Verwenden Sie keine Sonderzeichen, die in einem Dateinamen auf dem Zielbetriebssystem nicht unterstützt werden. Beispielsweise sollten die Zeichen /,\,* und @ nicht auf Windows verwendet werden. Diese Anforderung ist darauf zurückzuführen, dass das Plug‑in for MySQL versucht, einen Ordner mit demselben Namen wie der Auftragstitel zur vorübergehenden Wiederherstellung von Daten zu erstellen.

TIPP: Sie können auch auf Auswählen klicken und den entsprechenden Client im Dialogfeld Zielclient auswählen auswählen.

WICHTIG: Wenn Sie MySQL Enterprise Backup in einer Linux- oder UNIX-Umgebung verwenden, überprüfen Sie, ob die Dateieigentums- und Berechtigungsinformationen für die wiederhergestellten Daten mit denen übereinstimmen, die vor dem Sichern der Daten gespeichert wurden. Da das mysqlbackup-Hilfsprogramm diese Informationen während des Sicherungsvorgangs nicht speichert, können sich die Informationen nach Abschluss der Wiederherstellung unterscheiden. Weitere Informationen finden Sie unter https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-de/bugs.backup.html

Beispiele für Wiederherstellungsszenarien für MySQL Standard/Community

Um eine erfolgreiche 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. Die folgenden Themen enthalten Beispiele für verschiedene Wiederherstellungstypen und decken die jeweils erforderlichen Optionen ab.

Szenarien für die Wiederherstellung von ausschließlich Vollsicherungen

In den folgenden Beispielen hat der MySQL-DBA eine Sicherungsrichtlinie eingerichtet, in der Vollsicherungen täglich um 23:00 Uhr durchgeführt werden.

Am Montag 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 Montag um 6:00 Uhr vor der Ankunft des DBA am Arbeitsplatz gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Diese Entscheidung bedeutet, dass der DBA die Vollsicherung am Sonntag wiederherstellen und die PIT-Wiederherstellung für die aktuellen Binärprotokolle durchführen muss.

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 Ausgabe der fehlerhaften Anweisung 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.

Am Montag 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 Montag um 6:00 Uhr vor der Ankunft des DBA am Arbeitsplatz gelöscht hat.

Der DBA beschließt, die Wiederherstellung bis zu dem Zeitpunkt kurz vor der Ausgabe des Befehls „Tabelle löschen“ durchzuführen. Da der DBA eine präzisere Wiederherstellung wünscht, als zu einem geschätzten Zeitpunkt, an dem der Entwickler die Tabelle gelöscht hat, entscheidet sich der DBA für eine positionsbasierte Wiederherstellung. Dazu muss der DBA die Vollsicherung von Sonntag wiederherstellen und eine PIT-Wiederherstellung für die aktuellen Binärprotokolle durchführen.

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.

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. Darüber hinaus wünscht der DBA eine präzisere Wiederherstellung, daher entscheidet er sich für eine positionsbasierte Wiederherstellung. Dazu muss der DBA die Vollsicherung von Sonntag wiederherstellen und eine PIT-Wiederherstellung für die aktuellen Binärprotokolle durchführen.

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.

Szenarien für vollständige und inkrementelle Sicherungswiederherstellungen

Der DBA hat eine Sicherungsrichtlinie eingerichtet, in der Vollsicherungen jeden Sonntag um 23:00 Uhr und inkrementelle Sicherungen Montag bis Samstag um 23:00 Uhr durchgeführt werden. Da der DBA inkrementelle Sicherungen durchführt, werden die Binärprotokolle nach jeder inkrementellen Sicherung gelöscht. Dieser Prozess beschleunigt die Sicherung insgesamt, erfordert jedoch mehr Zeit und Schritte bei der Wiederherstellung.

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 inkrementellen Sicherung eine vollständige Wiederherstellung durchzuführen – die Sicherung, die am Mittwochabend durchgeführt wurde.

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.

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:

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:

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.

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:

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. Diese Wiederherstellung 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. Dazu muss der DBA die Vollsicherung von Sonntag und die nachfolgenden inkrementellen Sicherungen von Montag und Dienstag wiederherstellen und dann eine positionsbasierte PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchführen. 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 dem wiederhergestellten Binärprotokoll identifiziert wurde, wird eine PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

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. Dazu muss der DBA die Vollsicherung von Sonntag und die nachfolgenden inkrementellen Sicherungen von Montag und Dienstag wiederherstellen und dann eine positionsbasierte PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchführen. 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 Schritt 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: 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. Dazu muss der DBA die Vollsicherung von Sonntag und die nachfolgenden inkrementellen Sicherungen von Montag und Dienstag wiederherstellen und dann eine positionsbasierte PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchführen. 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 die PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

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. Dazu muss der DBA die Vollsicherung von Sonntag und die nachfolgenden inkrementellen Sicherungen von Montag und Dienstag wiederherstellen und dann eine positionsbasierte PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchführen. 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 die PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

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.