サポートと今すぐチャット
サポートとのチャット

NetVault Plug-in for MySQL 12.2 - Benutzerhandbuch

Einführung NetVault Backup Plug-in for MySQL Installieren und Entfernen des Plug-ins Konfigurieren des Plug-ins Sichern von Daten Wiederherstellen von Daten
Übersicht über die Wiederherstellung von Daten Wiederherstellen von Daten in MySQL Verwenden von erweiterten Wiederherstellungsverfahren für MySQL Standard/Community
Arbeiten mit nativer MySQL-Replikation Verwenden des Plug-ins in einer Failover-Clusterumgebung Fehlerbehebung

Sichern von Daten: Übersicht

Bevor Sie eine Sicherung abschließen, lesen Sie die Informationen in den folgenden Themen:

Wenn Sie die Option MySQL Standard/Community verwenden möchten, lesen Sie die folgenden Richtlinien und Informationen:

Wenn in Ihrer Umgebung Datenbanken verwendet werden, deren Namen Sonderzeichen wie Bindestriche enthalten, beachten Sie die folgenden Einschränkungen:

Wenn der Datenbankname Bindestriche enthält, werden MyISAM-Tabellen gesichert, wenn die MyISAM-Sicherungsmethode auf die Option mysqldump in Version 4.2 eingestellt ist. Die Performance von Sicherungen und Wiederherstellungen kann negativ beeinträchtigt werden.
Wenn die MyISAM-Sicherungsmethode auf die Standardoption Tabellendateien sperren und kopieren eingestellt ist und der Datenbankname Bindestriche enthält, werden MyISAM-Tabellen nicht gesichert. Sicherungen werden nicht erstellt, da das Plug-in MySQL-Befehle umgeht und versucht, die Tabellendateien direkt zu kopieren. Das Plug-in protokolliert eine Fehlermeldung, die darauf hinweist, dass die Tabellendatei nicht gefunden werden kann, und lässt dann den Sicherungsauftrag ohne Erstellung eines Speichersatzes fehlschlagen.
Wenn Sie das ursprüngliche Verhalten beibehalten und dennoch die Option Tabellendateien sperren und kopieren aus irgendeinem Grund verwenden möchten, z. B. bei Verwendung der Option mysqldump bei nicht optimaler Auswirkung auf die Performance, ist dies möglich. Setzen Sie dazu den Parameter „ValidateDatabaseDirectory“ in der Plug-in-Konfigurationsdatei nvmysql.cfg wie folgt manuell auf „TRUE“:
Verwenden des MIXED-Binärprotokollierungsformats

MySQL erzwingt die Verwendung der USE-Anweisung nicht, wenn das MIXED-Binärprotokollierungsformat verwendet wird. Daher empfiehlt Quest, dass alle Datenbankbenutzer und -programme sicherstellen, dass Tabellen, die geändert werden, 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.

Wenn in Ihrer Umgebung das MIXED-Binärprotokollierungsformat verwendet wird, kann dies verhindern, dass Einträge im Binärprotokoll während einer PIT-Wiederherstellung wiedergegeben werden. Während der Wiederherstellung verwendet das Plug-in mysqlbinlog mit der Option --database, um nur die Einträge wiederzugeben, die mit den Datenbanken zusammenhängen, die Sie für den Wiederherstellungsauftrag ausgewählt haben. Wenn --database nicht verwendet wird, werden alle Einträge wiedergegeben, was sich auf alle Datenbanken auswirkt. Wenn das MIXED-Binärprotokollierungsformat verwendet wird, werden Einträge so geschrieben, dass mysqlbinlog mit der Option ‑‑database einige oder alle Einträge möglicherweise nicht wiedergeben kann. Weitere Informationen finden Sie unter https://dev.mysql.com/doc/refman/5.7/de/mysqlbinlog.html#option_mysqlbinlog_database.

Um sicherzustellen, dass das MIXED-Binärprotokollierungsformat mit der Option --database korrekt funktioniert, müssen alle Transaktionen für bestimmte Aktualisierungen einer Datenbank unter einer USE-Anweisung ausgegeben werden, die die Datenbank auswählt.

Dasselbe Problem tritt auf, wenn die inkrementellen oder differenziellen Sicherungen nicht wiederhergestellt werden und mysqlbinlog das aktuelle Binärprotokoll vom MySQL-Server anwendet. Diese Situation tritt aufgrund der Art und Weise auf, wie das Binärprotokoll geschrieben wird, nicht aufgrund der Art, wie das Binärprotokoll in der Sicherung gespeichert wird.

WICHTIG: Stellen Sie sicher, dass Tabellen, die Sie ändern, zu der in der USE-Anweisung angegebenen Datenbank gehören, die für Transaktionen gilt, die über die MySQL-Eingabeaufforderung generiert werden. Sie gilt auch für Transaktionen, die von Skripts, Programmen und anderen Anwendungen generiert werden, die mit den MySQL Server-Datenbanken interagieren.

Die folgenden Beispiele zeigen verschiedene Möglichkeiten, wie sich MIXED auf das Wiederherstellungsverhalten auswirkt.

Beispiel 1: In diesem Beispiel wird eine Datenzeile in my_table von my_database eingefügt. Es gibt keine USE-Anweisung, daher ist die verwendete Datenbank die Standarddatenbank, z. B. die mysql-Datenbank. Wenn binlog_format auf MIXED eingestellt ist, wird die folgende Transaktion nicht wiedergegeben, wenn mysqlbinlog die Option ‑-databasemy_database auf das Binärprotokoll anwendet.
Beispiel 2: In diesem Beispiel wird eine Datenzeile in my_table von my_database eingefügt. Es gibt eine USE-Anweisung, aber es wird eine andere Datenbank angegeben, d. h. my_database ist in der USE-Anweisung nicht ausgewählt. Wenn binlog_format auf MIXED eingestellt ist, wird die folgende Transaktion nicht wiedergegeben, wenn mysqlbinlog die Option ‑-databasemy_database auf das Binärprotokoll anwendet.
Beispiel 3: In diesem Beispiel wird eine Datenzeile in my_table von my_database eingefügt und my_database wird in einer USE-Anweisung ausgewählt. Wenn binlog_format auf MIXED eingestellt ist, wird die folgende Transaktion wiedergegeben, wenn mysqlbinlog die Option ‑-databasemy_database auf das Binärprotokoll anwendet.
Beispiel 4: In diesem Beispiel gibt es zwei Einfügeabfragen. Die erste Einfügung erfolgt für my_database, die sich von der in der USE-Anweisung ausgewählten Datenbank unterscheidet. Die zweite Einfügung erfolgt im Rahmen einer USE-Anweisung, die my_database auswählt. Wenn „binlog_format“ auf MIXED eingestellt ist, wird die erste Einfügung nicht wiedergegeben, da my_database nicht in der USE-Anweisung angegeben ist, aber die zweite Einfügung wird erneut wiedergegeben, da my_database in der USE-Anweisung angegeben ist.

Wenn Sie die Option MySQL Enterprise Backup verwenden möchten, lesen Sie die folgenden Richtlinien und Informationen:

Beispiel: Sie haben eine MySQL-Instanz mit zwei Datenbanken – DB1 und DB2. Jede Datenbank enthält zwei Tabellen: DB1 hat T1_InnoDB und T1_MyISAM und DB2 hat T2_InnoDB und T2_MyISAM. Wenn Sie T1_MyISAM und T2_MyISAM sichern, werden auch T1_InnoDB und T2_InnoDB gesichert. Wenn Sie eine der InnoDB-Tabellen einschließen, wird nur diese InnoDB-Tabelle gesichert. Wenn Sie eine der Datenbanken auswählen, werden nur die Tabellen in der Datenbank gesichert.
Beispiel: Sie haben eine MySQL-Instanz mit zwei Datenbanken – DB1 und DB2. Jede Datenbank enthält zwei Tabellen: DB1 hat T1_InnoDB und T1_MyISAM und DB2 hat T2_InnoDB und T2_MyISAM. Wenn Sie DB1 und DB2 sichern und T1_InnoDB und T2_InnoDB ausschließen, werden auch T1_InnoDB und T2_InnoDB gesichert. Wenn Sie nur eine der beiden InnoDB-Tabellen ausschließen, wird nur die andere InnoDB-Tabelle gesichert.
Diese Beschreibung spiegelt das aktuelle Verhalten von MySQL Enterprise Backup, dem mysqlbackup-Hilfsprogramm, wider. Dieses Verhalten kann sich in einer zukünftigen Version nach 3.12 von MySQL ändern.
In MySQL 5.6 und höher ist die Konfigurationsoption innodb_file_per_table standardmäßig aktiviert. Alle InnoDB-Tabellen, die mit deaktivierter innodb_file_per_table-Option erstellt wurden, werden im InnoDB-Tabellenbereich gespeichert; sie können nicht aus der Sicherung ausgelassen werden. Wenn Sie eine InnoDB-Tabelle außerhalb des Tabellenbereichs platzieren müssen, erstellen Sie sie, während die Option innodb_file_per_table in MySQL aktiviert ist. Jede IBD-Datei enthält die Daten und Indizes nur einer Tabelle.

Definieren einer Sicherungsstrategie

Beantworten Sie bei der Definition einer MySQL-Sicherungsstrategie die folgenden Fragen:

Soll ich die Option MySQL Standard/Community oder MySQL Enterprise Backup verwenden? Selbst wenn Sie beide Versionen in Ihrer Umgebung implementiert haben, können Sie nur eine Strategie mit dem Plug-in verwenden. Verwenden Sie entweder die MEB-basierte Methode oder die mysqldump-basierte Methode. Sie können keine Mischung aus beiden Methoden verwenden.
Wenn Sie die MEB-basierte Option verwenden, wird das mysqlbackup-Hilfsprogramm oder das anwendbare NetVault Backup-Skript einmal für alle Datenbankobjekte ausgeführt, die Sie für die Sicherung auswählen, und ein mysqlbackup-Ausgabeprotokoll wird im Auftragsprotokoll eingefügt. Das Sichern von Daten umfasst zwei Phasen. In der ersten Phase werden alle InnoDB-Tabellen kopiert. In der zweiten Phase werden alle anderen Tabellentypen kopiert. Zusätzlich zur Unterstützung von Hotbackups von InnoDB-Tabellen unterstützt die MEB-basierte Option eine verbesserte Sicherungsperformance.

Die Beantwortung dieser Fragen hilft Ihnen bei der Definition des Typs und der Häufigkeit von Sicherungen, die implementiert werden sollten.

Die Sicherungstypen für MySQL Standard/Community im Überblick

Wenn Sie die Option MySQL Standard/Community verwenden, nutzt das Plug-in mysqldump, um die folgenden Sicherungstypen auszugeben:

Zu verstehen, wie sich diese zwei Sicherungen voneinander unterscheiden, ist der erste Schritt bei der Auswahl einer geeigneten Sicherungssequenz, die den Datensicherheitsanforderungen für jede MySQL-Instanz entspricht.

Bei einer Vollsicherung für die Option MySQL Standard/Community verwendet das Plug-in das Hilfsprogramm mysqldump, um alle in der Instanz enthaltenen Datenbanken zu sichern. Vollsicherungen bilden die Grundlage jeder Sicherungsstrategie, da sie den Ausgangspunkt für fast jedes Wiederherstellungsszenario bilden. Mit dem Plug-in erstellte Vollsicherungen können verwendet werden, um eine ganze Instanz, einzelne oder mehrere Datenbanken und einzelne oder mehrere Tabellen wiederherzustellen.

Die Option Binärprotokolle nach vollständiger oder inkrementeller Sicherung bereinigen stellt sicher, dass Binärprotokolle nach einer vollständigen oder inkrementellen Sicherung bereinigt werden. Diese Option ist standardmäßig aktiviert, wenn das Plug-in mit einer standardmäßigen MySQL-Serverkonfiguration verwendet wird, MySQL-Replikation aktivieren deaktiviert und Recovery auf einen Point-in-Time aktivieren aktiviert ist. Sie ist deaktiviert, wenn das Plug-in mit einem Cluster verbunden ist. Sie müssen die Löschung der Binärprotokolle außerhalb des Plug-ins verwalten.

WICHTIG: Verwenden Sie in einer gemischten Umgebung, in der ein NetVault Backup Server sowohl geclusterte als auch standardmäßige MySQL Server verwaltet, keinen Sicherungsoptionssatz, der für einen standardmäßigen MySQL Server erstellt wurde, für einen MySQL-basierten Cluster erneut.

Wenn Sie die Option Binärprotokolle bereinigen... nicht auswählen, verfolgt das Plug-in das letzte gesicherte Protokoll in seiner Konfigurationsdatei; Sie können Binärprotokolle nach eigenem Ermessen manuell bereinigen. Wenn Sie beispielsweise eine MySQL-Replikationsumgebung verwenden, in der Sie Binärprotokolle erst von der Master-Instanz bereinigen möchten, nachdem sie auf die Slave-Instanz repliziert wurden, sind Sie für das manuelle Bereinigen der Binärprotokolle verantwortlich.

Eine inkrementelle Sicherung sichert die Transaktionsprotokolle, die seit der letzten vollständigen oder inkrementellen Sicherung generiert wurden, gefolgt von der Bereinigung der Binärprotokolle. Da die Binärprotokolle instanzbasiert sind, werden die Transaktionsprotokolle für jede Datenbank als Einheit gesichert und bereinigt.

Inkrementelle Sicherungen sind für die Reduzierung von Datenverlusten nach einem Medienausfall oder einer Datenbeschädigung unerlässlich. Sie können inkrementelle Sicherungen verwenden, um eine Wiederherstellung auf einen Zeitpunkt vor und nach einer Datenbeschädigung durchzuführen, z. B. eine falsche Aktualisierung oder eine nicht verarbeitete Tabelle. Im Gegensatz zu Vollsicherungen benötigen inkrementelle Sicherungen während des Sicherungsvorgangs keinen schreibgeschützten Zugriff.

Für inkrementelle MySQL-Sicherungen müssen Sie die MySQL-Instanz mit der Option ‑log-bin starten, die das Binärprotokoll aktiviert. Dieses Verfahren wird in Aktivieren des Binärprotokolls auf dem MySQL-Server (nur Standard/Community-Option) beschrieben. Weitere Informationen finden Sie im Abschnitt zu Binärprotokollen im MySQL-Referenzhandbuch .

Wie bereits beschrieben, stellt die Option Binärprotokolle nach vollständiger oder inkrementeller Sicherung bereinigen sicher, dass Binärprotokolle nach einer vollständigen oder inkrementellen Sicherung bereinigt werden. Wenn Sie diese Option nicht auswählen, verfolgt das Plug-in das letzte gesicherte Protokoll in seiner Konfigurationsdatei; Sie können Binärprotokolle nach eigenem Ermessen manuell bereinigen.

Bei einer differenziellen Sicherung werden nur die Transaktionsprotokolle gesichert, die seit der letzten vollständigen oder inkrementellen Sicherung erstellt wurden. Die Binärprotokolle werden jedoch nach Abschluss der Sicherung nicht bereinigt. Aus diesem Grund erhöhen sich die Größe und Dauer der nachfolgenden differenziellen Sicherungen. Die Größe und Dauer nehmen zu, da jede Sicherung dieses Typs die Binärprotokolle enthält, die auch in der vorherigen differenziellen Sicherung enthalten waren und die Binärprotokolle, die seit der vorherigen differenziellen Sicherung generiert wurden. Wenn beispielsweise eine vollständige Sicherung am Sonntag durchgeführt wurde und differenzielle Sicherungen von Montag bis Samstag geplant sind, enthält die differenzielle Sicherung von Montag die Binärprotokolle, die seit der vollständigen Sicherung am Sonntag generiert wurden, während die differenzielle Sicherung von Dienstag die Binärprotokolle enthält, die am Montag generiert wurden, und die Dateien, die am Dienstag generiert wurden. Das Differenzial am Mittwoch umfasst die Binärprotokolle für Montag, Dienstag, Mittwoch usw.

Ähnlich wie bei einer inkrementellen Sicherung kann ein Differenzial auch dazu verwendet werden, den Datenverlust nach einem Medienausfall oder einer Datenbeschädigung zu reduzieren, wobei die Wiederherstellung auf einen Zeitpunkt vor und nach dem Ausfall oder der Beschädigung erfolgen kann. Im Gegensatz zu einer Vollsicherung erfordert eine differenzielle Sicherung während der Sicherung keinen schreibgeschützten Zugriff.

Für differenzielle Sicherungen müssen Sie die MySQL-Instanz mit der Option ‑log-bin starten, die das Binärprotokoll aktiviert. Dieses Verfahren wird in Aktivieren des Binärprotokolls auf dem MySQL-Server (nur Standard/Community-Option) beschrieben. Weitere Informationen finden Sie im Abschnitt zu Binärprotokollen im MySQL-Referenzhandbuch .

Da inkrementelle Sicherungen die Binärprotokolle nach der Sicherung bereinigen, werden nachfolgende inkrementelle Sicherungen schneller, da nur die Binärprotokolle, die seit der letzten inkrementellen Sicherung erstellt wurden, gesichert werden. Wiederherstellungssequenzen, die inkrementelle Sicherungen verwenden, erfordern jedoch, dass jede inkrementelle Sicherungen, die zwischen der vollständigen Sicherung und dem Fehlerpunkt durchgeführt wurde, nacheinander wiederhergestellt werden muss. Dieser Prozess kann zu einer längeren Wiederherstellung und einem höheren DBA-Bedarf führen, um mehrere Wiederherstellungsaufträge zu initiieren.

Da differenzielle Sicherungen die Binärprotokolle nach der Sicherung nicht bereinigen, dauert jede nachfolgende differenzielle Sicherung länger, da alle Binärprotokolle seit der letzten Vollsicherung in der Sicherung enthalten sind. Wiederherstellungssequenzen, die differenzielle Sicherungen verwenden, erfordern jedoch, dass nur eine differenzielle Sicherung wiederhergestellt wird, nachdem die vollständige Sicherung wiederhergestellt wurde. Dieser Prozess führt zu schnelleren Wiederherstellungen, da während des Wiederherstellungsprozesses weniger DBA-Eingriffe erforderlich sind.

Manchmal muss eine Sicherung für einen speziellen Zweck durchgeführt werden und sollte sich nicht auf die vollständige Sicherung und die Wiederherstellungsverfahren für eine komplette Datenbank auswirken. Sicherungen können beispielsweise eine Quelle für eine Testumgebung oder eine erste Synchronisierung für eine Replikations-Slave-Instanz sein. Individuelle Datenbank-/kopierbasierte Tabellensicherungen sind für diese speziellen Zwecke konzipiert, da sie das „Kopieren“ einer MySQL-Umgebung ermöglichen. Kopierbasierte Sicherungen sind unabhängig von einer festgelegten Reihenfolge von Sicherungen und wirken sich nicht auf die Wiederherstellbarkeit von vollständigen oder differenziellen Sicherungen aus. Sie sollten jedoch nicht als Ersatz für eine vollständige Sicherungsstrategie verwendet werden.

Wie für individuelle Datenbank-/kopierbasierte Tabellensicherungen beschrieben, wird die Option „Kopiesicherungen der gesamten Datenbank“ nur für spezielle Zwecke verwendet, da sie eine Kopie der ausgewählten MySQL-Datenbanken erstellt, einschließlich aller entsprechenden InnoDB-Tabellen der ausgewählten Datenbanken. Kopiesicherungen sind unabhängig von einer festgelegten Reihenfolge von Sicherungen und wirken sich nicht auf die Wiederherstellbarkeit von vollständigen oder differenziellen Sicherungen aus. Sie sollten jedoch nicht als Ersatz für eine vollständige Sicherungsstrategie verwendet werden.

Die Option „Kopiesicherungen der gesamten Datenbank“ sichert für jede ausgewählte Datenbank, selbst wenn nur eine Tabelle der Datenbank ausgewählt ist, die gesamte Datenbank. Mit dieser Option können Sie einzelne Datenbanken, aber keine einzelnen Tabellen für die Sicherung auswählen. Darüber hinaus unterstützt diese Option nur die Sicherung von InnoDB-Tabellen.

Mit der Option „Individuelle Datenbank-/kopierbasierte Tabellensicherung“ können Sie einzelne Datenbanken und einzelne Tabellen auswählen und InnoDB- und MyISAM-Tabellen in die Sicherung aufnehmen. Sicherungen werden jedoch normalerweise schneller für die Option „Kopiesicherungen der gesamten Datenbank“ als für die Option „Individuelle Datenbank-/kopierbasierte Tabellensicherung“ abgeschlossen.

Die Sicherungstypen für MySQL Enterprise Backup im Überblick

Für die Option MySQL Enterprise Backup führt das Plug-in den mysqlbackup-Befehl einmal für alle ausgewählten Datenbankobjekte aus, um die folgenden Sicherungstypen zu erreichen: Vollständig, inkrementell und TTS.

Bei einer Vollsicherung für die Option MySQL Enterprise Backup verwendet das Plug-in das mysqlbackup-Hilfsprogramm oder das entsprechende NetVault Backup-Skript, um jedes ausgewählte Datenbankobjekt in der Instanz zu sichern. Vollsicherungen bilden die Grundlage jeder Sicherungsstrategie, da sie den Ausgangspunkt für fast jedes Wiederherstellungsszenario bilden. Mit dem Plug-in erstellte Vollsicherungen können verwendet werden, um eine ganze Instanz, einzelne oder mehrere Datenbanken und einzelne oder mehrere Tabellen wiederherzustellen.

Für eine InnoDB-Tabelle werden nur Daten gesichert, die seit der letzten vollständigen oder inkrementellen Sicherung geändert wurden. Bei einer Nicht-InnoDB-Tabelle wird die gesamte Tabelle gesichert, wenn seit der letzten vollständigen oder inkrementellen Sicherung Änderungen in der Tabelle vorgenommen wurden.

Wenn Sie eine TTS-Sicherung durchführen, gibt das Plug-in eine Vollsicherung aus und fügt die MySQL-Option --use-tts hinzu.

Wenn Sie TTS-Sicherungen erstellen möchten, beachten Sie die folgenden Einschränkungen:

Nur Tabellen, die mit aktivierter Option innodb_file_per_table erstellt wurden, werden in die Sicherung eingeschlossen.

Weitere Einschränkungen bei der Verwendung der Option --use-tts finden Sie unter https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/de/backup-partial-options.html.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択