NetVault Plug-in for MySQL 12.0 - 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 dürfen die Zeichen /,\,* und @ unter Windows nicht verwendet werden. Diese Anforderung besteht, weil das Plug‑in für MySQL versucht, einen Ordner mit demselben Namen wie der Jobtitel für die 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, stellen Sie sicher, dass die Datei- und Berechtigungsinformationen für die wiederhergestellten Daten mit denen übereinstimmen, bevor die Daten gesichert wurden. Da das Dienstprogramm mysqlbackup diese Informationen während des Sicherungsvorgangs nicht aufzeichnet, können die Informationen nach Abschluss der Wiederherstellung abweichen. Weitere Informationen finden Sie unter https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-en/bugs.backup.html.

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

Um nach einem Fehler oder einer Datenbeschädigung erfolgreich wiederhergestellt zu werden, müssen verschiedene Einstellungen vorgenommen werden, wenn der Job in Bezug auf die für die Wiederherstellung ausgewählten Daten und Optionen auf der Registerkarte Optionen eingerichtet wird. Die folgenden Themen bieten Beispiele für verschiedene Arten der Wiederherstellung und decken die spezifischen Optionen ab.

Wiederherstellungsszenarien – Nur vollständige Sicherung

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

Am Montag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Montag um 6:00 Uhr versehentlich gelöscht hat, bevor der DBA am Arbeitsplatz eintraf.

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Diese Entscheidung bedeutet, dass der DBA die vollständige Sicherung von Sonntag wiederherstellen und die PIT-Wiederherstellung mit den aktuellen Binärprotokollen durchführen muss.

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Der DBA möchte außerdem die Transaktionen wiederherstellen, die in den verbleibenden Tabellen aus der Zeit nach dem Erstellen der fehlerhaften Anweisung und bis zum Ende der aktuellen Binärprotokolle aufgetreten sind. Durch diese Entscheidung wird sichergestellt, dass er so viele der Transaktionen wie möglich wiederhergestellt hat, zusätzlich zur Wiederherstellung der gelöschten Tabelle.

Am Montag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Montag um 6:00 Uhr versehentlich gelöscht hat, bevor der DBA am Arbeitsplatz eintraf.

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Da der DBA eine genauere Wiederherstellung wünscht als die Schätzung der Zeit, zu der der Entwickler die Tabelle löschte, wählt der DBA eine positionsbasierte Wiederherstellung. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung von Sonntag wiederherstellen und eine PIT-Wiederherstellung mit den aktuellen Binärprotokollen durchführen.

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

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Der DBA möchte außerdem die Transaktionen wiederherstellen, die in den verbleibenden Tabellen aus der Zeit nach dem Löschen der Auftragstabelle und bis zum Ende der aktuellen Binärprotokolle aufgetreten sind. Durch diese Entscheidung wird sichergestellt, dass er so viele der Transaktionen wie möglich wiederhergestellt hat, zusätzlich zur Wiederherstellung der gelöschten Tabelle. Darüber hinaus möchte der DBA eine genauere Wiederherstellung erzielen, sodass er eine positionsbasierte Wiederherstellung verwenden möchte. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung von Sonntag wiederherstellen und eine PIT-Wiederherstellung mit den aktuellen Binärprotokollen durchführen.

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

Wiederherstellungsszenarien für vollständige und inkrementelle Sicherungen

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

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie irgendwann am Donnerstagmorgen versehentlich gelöscht hat, bevor der DBA am Arbeitsplatz eintraf.

Der DBA entscheidet, eine vollständige Wiederherstellung bis zum Zeitpunkt der letzten inkrementellen Sicherung durchzuführen: Die Sicherung erfolgte am Mittwochabend.

In den folgenden Beispielen wird ein Szenario mit vollständigen und inkrementellen Sicherungen durchgeführt, und der DBA möchte Daten zu einem bestimmten Zeitpunkt wiederherstellen.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Mittwoch um 20:00 Uhr versehentlich gelöscht hat

Der DBA muss eine Wiederherstellung durchführen, die die Datenbank bis zum richtigen Zeitpunkt wiederherstellen kann, direkt bevor der Entwickler am Mittwoch um 20:00 Uhr die Tabelle löschte. Daher werden die folgenden Phasen durchgeführt:

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Mittwoch um 20:00 Uhr versehentlich gelöscht hat

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl um 20:00 Uhr erteilt wurde. Der DBA möchte außerdem die Transaktionen wiederherstellen, die in den verbleibenden Tabellen nach dem Löschen der Auftragstabelle und bis zum Ende der gesicherten Binärprotokolle aufgetreten sind. Durch diese Entscheidung wird sichergestellt, dass er so viele der Transaktionen wie möglich wiederhergestellt hat, zusätzlich zur Wiederherstellung der gelöschten Tabelle. Daher werden die folgenden Phasen durchgeführt:

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Donnerstag um 06:00 Uhr versehentlich gelöscht hat

Der DBA muss eine Wiederherstellung durchführen, die die Datenbank bis zum richtigen Zeitpunkt wiederherstellen kann, direkt bevor der Entwickler am Donnerstag um 06:00 Uhr die Tabelle löschte.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Donnerstag um 06:00 Uhr versehentlich gelöscht hat

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Der DBA möchte außerdem die Transaktionen wiederherstellen, die in den verbleibenden Tabellen aus der Zeit nach dem Löschen der Auftragstabelle und bis zum Ende der aktuellen Binärprotokolle aufgetreten sind. Durch diese Entscheidung wird sichergestellt, dass er so viele der Transaktionen wie möglich wiederhergestellt hat, zusätzlich zur Wiederherstellung der gelöschten Tabelle. Daher werden die folgenden Phasen durchgeführt:

In den folgenden Beispielen wird ein Szenario mit vollständigen und inkrementellen Sicherungen durchgeführt, und der DBA möchte Daten zu einem bestimmten Zeitpunkt wiederherstellen, aber eine exaktere Methode zum Festlegen der Zeit verwenden. Diese Wiederherstellung wird anhand der identifizierten „Positionswerte“ durchgeführt, die in den MySQL-Binärprotokollen vorhanden sind.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Mittwoch um 20:00 Uhr versehentlich gelöscht hat

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Darüber hinaus möchte der DBA eine genauere Wiederherstellung erzielen, sodass er eine positionsbasierte Wiederherstellung verwenden möchte. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung 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. Die folgenden Phasen verdeutlichen diesen Prozess:

In dieser Phase werden nur die Binärprotokolle, die in der inkrementellen Datensicherung von Mittwochnacht aufgezeichnet wurden, an einem temporären Standort wiederhergestellt. Dieser Prozess ermöglicht es dem DBA, die spezifische Position im Protokoll zu ermitteln, die angibt, wann die Auftragstabelle gelöscht wurde.

Verwenden Sie das Dienstprogramm „mysqlbinlog“ mit den wiederhergestellten Binärprotokollen: Dieser Schritt erfolgt außerhalb von NetVault Backup, um die Position des Befehls zum Löschen der Tabelle zu ermitteln, den der DBA nicht wiederherstellen möchte. (Weitere Informationen zu diesem Dienstprogramm und dem Prozess finden Sie im MySQL-Referenzhandbuch.) In diesem Prozess hat der DBA den Befehl zum Löschen der Tabelle als Protokollposition „805“ im Binärprotokoll „MYSQLSVR-bin.000009“ identifiziert, das am temporären Speicherort auf dem MySQL-Server wiederhergestellt wurde, und beide Werte wurden notiert.

Mit der im wiederhergestellten Binärprotokoll identifizierten Position wird eine PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Mittwoch um 20:00 Uhr versehentlich gelöscht hat

Der DBA entscheidet sich für eine Wiederherstellung bis zu dem Zeitpunkt, direkt bevor der Löschbefehl erteilt wurde. Der DBA möchte außerdem die Transaktionen wiederherstellen, die in den verbleibenden Tabellen aus der Zeit nach dem Löschen der Auftragstabelle und bis zum Ende der gesicherten Binärprotokolle aufgetreten sind. Darüber hinaus möchte der DBA eine genauere Wiederherstellung erzielen, sodass er eine positionsbasierte Wiederherstellung verwenden möchte. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung 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. Die folgenden Phasen verdeutlichen diesen Prozess:

In dieser Phase werden nur die Binärprotokolle, die in der inkrementellen Datensicherung von Mittwochnacht aufgezeichnet wurden, an einem temporären Standort wiederhergestellt. Dieser Schritt ermöglicht es dem DBA, die spezifische Position im Protokoll zu ermitteln, die angibt, wann die Auftragstabelle gelöscht wurde.

Verwenden Sie das Dienstprogramm „mysqlbinlog“ mit den wiederhergestellten Binärprotokollen: Dieser Schritt erfolgt außerhalb von NetVault Backup, um die Position des Befehls zum Löschen der Tabelle zu ermitteln, den der DBA nicht wiederherstellen möchte. (Weitere Informationen zu diesem Dienstprogramm und dem Prozess finden Sie im MySQL-Referenzhandbuch.) In diesem Prozess hat der DBA den Befehl zum Löschen der Tabelle als Protokollposition „805“ im Binärprotokoll „MYSQLSVR-bin.000009“ identifiziert, das am temporären Speicherort auf dem MySQL-Server wiederhergestellt wurde, und beide Werte wurden notiert.

Mit der in den wiederhergestellten Binärprotokollen identifizierten Position wird eine PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

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

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Donnerstag um 06:00 Uhr versehentlich gelöscht hat

Der DBA muss eine Wiederherstellung durchführen, die die Datenbank bis zum richtigen Zeitpunkt wiederherstellen kann, direkt bevor der Entwickler am Donnerstag um 06:00 Uhr die Tabelle löschte. Darüber hinaus möchte der DBA eine genauere Wiederherstellung erzielen, sodass er eine positionsbasierte Wiederherstellung verwenden möchte. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung 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. Die folgenden Phasen verdeutlichen diesen Prozess:

Verwenden Sie das Dienstprogramm „mysqlbinlog“ für die aktuellen Binärprotokolle: Dieser Schritt erfolgt außerhalb von NetVault Backup, um die Position des Befehls zum Löschen der Tabelle zu ermitteln, den der DBA nicht wiederherstellen möchte. (Weitere Informationen zu diesem Dienstprogramm und dem Prozess finden Sie im MySQL-Referenzhandbuch.) In diesem Prozess hat der DBA den Befehl zum Löschen der Tabelle als Protokollposition „805“ im aktuellen Binärprotokoll „MYSQLSVR-bin.000009“ identifiziert.

Mit der in den wiederhergestellten Binärprotokollen identifizierten Position wird eine PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

Am Donnerstag um 9:00 Uhr erfährt der DBA, dass Benutzer in der Tabelle Aufträge auf den Fehler „Tabelle nicht gefunden“ stoßen. Der DBA erfährt dann, dass die Tabelle nicht mehr existiert, weil ein Entwickler sie am Donnerstag um 06:00 Uhr versehentlich gelöscht hat

Der DBA muss eine Wiederherstellung durchführen, die die Datenbank bis zum richtigen Zeitpunkt wiederherstellen kann, direkt bevor der Entwickler am Donnerstag um 06:00 Uhr die Tabelle löschte. Darüber hinaus möchte der DBA eine genauere Wiederherstellung erzielen, sodass er eine positionsbasierte Wiederherstellung verwenden möchte. Um diesen Vorgang abzuschließen, muss der DBA die vollständige Sicherung 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. Die folgenden Phasen verdeutlichen diesen Prozess:

Verwenden Sie das Dienstprogramm „mysqlbinlog“ für die aktuellen Binärprotokolle: Dieser Schritt erfolgt außerhalb von NetVault Backup, um die Position des Befehls zum Löschen der Tabelle zu ermitteln, den der DBA nicht wiederherstellen möchte. (Weitere Informationen zu diesem Dienstprogramm und dem Prozess finden Sie im MySQL-Referenzhandbuch.) In diesem Prozess hat der DBA den Befehl zum Löschen der Tabelle als Protokollposition „805“ im aktuellen Binärprotokoll „MYSQLSVR-bin.000009“ identifiziert.

Mit der in den wiederhergestellten Binärprotokollen identifizierten Position wird eine PIT-Wiederherstellung mit der inkrementellen Sicherung von Mittwoch durchgeführt.

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