Tchater maintenant avec le support
Tchattez avec un ingénieur du support

NetVault Plug-in for MySQL 12.0 - Benutzerhandbuch

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

Sichern von Daten: Übersicht

Bevor Sie eine Sicherung durchführen, 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 Ihre Umgebung Datenbanken verwendet, deren Namen Sonderzeichen wie Bindestriche enthalten, beachten Sie die folgenden Einschränkungen:

Wenn der Datenbankname Bindestriche enthält, werden die MyISAM-Tabellen gesichert, wenn die MyISAM-Sicherungsmethode auf die Option mysqldump gesetzt ist, die mit Version 4.2 eingeführt wurde. Die Performance von Sicherungen und Wiederherstellungen kann negativ beeinflusst werden.
Wenn die MyISAM-Sicherungsmethode auf die Standardeinstellung Tabellendateien sperren und kopieren eingestellt ist und der Datenbankname Bindestriche enthält, werden die MyISAM-Tabellen nicht gesichert. Sicherungen werden nicht generiert, weil das Plug-in MySQL-Befehle umgeht und versucht, die Tabellendateien direkt zu kopieren. Das Plug-in protokolliert eine Fehlermeldung, die angibt, dass die Tabellendatei nicht gefunden werden kann, woraufhin der Sicherungsjob fehlschlägt, ohne dass ein Speichersatz erstellt wird.
Wenn Sie das ursprüngliche Verhalten beibehalten möchten und die Option Tabellendateien sperren und kopieren aus beliebigen Gründen weiterhin verwenden möchten, z. B. wegen nicht unerheblichen Auswirkungen auf die Leistung, wenn Sie die Option mysqldump verwenden, können Sie das tun. Hierzu muss der Parameter „ValidateDatabaseDirectory“ in der Plug-in-Konfigurationsdatei „nvmysql.cfg“ wie folgt manuell festgelegt werden:
Verwenden des gemischten binären Protokollierungsformats

MySQL erzwingt die Verwendung der Anweisung USE nicht, wenn das gemischte Binärprotokollformat verwendet wird. Daher empfiehlt Quest, dass alle Datenbankbenutzer und -programme sicherstellen, dass Tabellen, die geändert werden, in der Datenbank durch USE ausgewählt worden sind und keine datenbankübergreifenden Aktualisierungen ausgegeben werden. Wenn diese Richtlinie nicht für Ihre Umgebung geeignet ist, empfiehlt Quest, das gemischte Binärprotokollierungsformat nicht zu verwenden.

Wenn Ihre Umgebung das gemischte Binärprotokollformat verwendet, kann es vorkommen, dass Binärprotokolleinträge während einer PIT-Wiederherstellung nicht wiedergegeben werden. Während der Wiederherstellung verwendet das Plug-in mysqlbinlog mit der Option „--database“, um nur die Einträge wiederzugeben, die sich auf die Datenbanken beziehen, die Sie für den Wiederherstellungsjob ausgewählt haben. Wenn „--database“ nicht verwendet wird, werden alle Einträge wiedergegeben, die sich auf alle Datenbanken auswirken. Wenn das gemischte Binärprotokollformat verwendet wird, werden Einträge in einer Weise geschrieben, die mysqlbinlog mit der Option „--database“ an der Wiedergabe einiger oder aller Einträge hindert. Weitere Informationen finden Sie unter https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog.html#option_mysqlbinlog_database.

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

Diese Situation 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, in der das Binärprotokoll geschrieben wird, und nicht aufgrund dessen, wie das Binärprotokoll in der Sicherung gespeichert wird.

WICHTIG: Stellen Sie für Transaktionen, die über die MySQL-Eingabeaufforderung generiert werden, sicher, dass Tabellen, die Sie ändern, zu der in der USE-Anweisung angegebenen Datenbank gehören. Dies gilt auch für Transaktionen, die durch Skripte, Programme und andere Anwendungen generiert werden, die mit den MySQL-Serverdatenbanken interagieren.

Die folgenden Beispiele zeigen verschiedene Methoden, in denen die Option gemischt Auswirkungen auf das Wiederherstellungsverhalten haben.

Beispiel 1: In diesem Beispiel wird eine Datenzeile in my_table von my_database eingefügt. Es gibt keine USE-Anweisung, deshalb ist die verwendete Datenbank die Standarddatenbank, z. B. die Datenbank mysql. Wenn binlog_format auf MIXED eingestellt ist, wird die folgende Transaktion nicht wiedergegeben, wenn mysqlbinlog die Option „‑-database my_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 eine andere Datenbank ist angegeben. Das heißt, 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 „‑-database my_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 „‑-database my_database“ auf das Binärprotokoll anwendet.
Beispiel 4: In diesem Beispiel gibt es zwei Einfügeabfragen. Das erste Einfügen erfolgt für my_database, die sich von der in der USE-Anweisung ausgewählten Datenbank unterscheidet. Das zweite Einfügen erfolgt im Rahmen einer USE-Anweisung, die my_database auswählt. Wenn „binlog_format“ auf MIXED festgelegt ist, wird das erste Einfügen nicht wiedergegeben, weil my_database nicht in der USE-Anweisung angegeben ist, aber das zweite Einfügen wird wiedergegeben, weil 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 enthält T1 und T1_InnoDB_MyISAM und DB2 verfügt über T2_InnoDB and T2_MyISAM. Wenn Sie T1_MyISAM und T2_MyISAM sichern, werden T1_InnoDB und T2_InnoDB ebenfalls 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 dieser Datenbank gesichert.
Beispiel: Sie haben eine MySQL-Instanz mit zwei Datenbanken, DB1 und DB2. Jede Datenbank enthält zwei Tabellen: DB1 enthält T1 und T1_InnoDB_MyISAM und DB2 verfügt über T2_InnoDB and T2_MyISAM. Wenn Sie DB1 und DB2 sichern und T1_InnoDB und T2_InnoDB ausschließen, werden T1_InnoDB und T2_InnoDB ebenfalls gesichert. Wenn Sie nur eine der beiden InnoDB-Tabellen ausschließen, wird nur die andere InnoDB-Tabelle gesichert.
Diese Beschreibung spiegelt das aktuelle Verhalten des Dienstprogramms mysqlbackup, MySQL Enterprise Backup, 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 der deaktivierten Option innodb_file_per_table erstellt werden, werden im InnoDB-Systemtablespace gespeichert; sie können nicht aus der Sicherung ausgeschlossen werden. Wenn Sie eine InnoDB-Tabelle außerhalb des Tablespace platzieren müssen, erstellen Sie diese, während die Option innodb_file_per_table in MySQL aktiviert ist. Jede .ibd-Datei enthält die Daten und Indexe von nur einer Tabelle.

Definieren einer Sicherungsstrategie

Beantworten Sie beim Festlegen einer MySQL-Sicherungsstrategie die folgenden Fragen:

Soll die Option MySQL Standard/Community oder MySQL Enterprise Backup verwendet werden? Auch 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; es ist nicht möglich, eine Mischung aus beiden zu verwenden.
Wenn Sie die Option „MEB-basiert“ verwenden, wird das Dienstprogramm mysqlbackup oder das entsprechende NetVault Backup Skript einmal für alle Datenbankobjekte ausgeführt, die Sie für die Sicherung auswählen, und ein Ausgabeprotokoll von mysqlbackup ist im Jobprotokoll enthalten. Das Sichern von Daten erfolgt in zwei Phasen. In der ersten Phase werden alle InnoDB-Tabellen kopiert. In der zweiten Phase werden alle anderen Arten von Tabellen kopiert. Neben der Unterstützung eines Hotbackups von InnoDB-Tabellen unterstützt die MEB-basierte Option eine verbesserte Sicherungsleistung.

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

Prüfen der Sicherungstypen für MySQL Standard/Community

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

Das Verständnis dafür, wie diese Sicherungen sich unterscheiden, ist der erste Schritt bei der Auswahl einer geeigneten Sicherungssequenz, die den Anforderungen der Datensicherheit für jede MySQL-Instanz entspricht.

In einer vollständigen Sicherung für die Option MySQL-Standard/Community verwendet das Plug-in das Dienstprogramm mysqldump, um jede Datenbank in der Instanz zu sichern. Vollständige Sicherungen bilden die Grundlage für jede Sicherungsstrategie, da sie den Ausgangspunkt für fast jedes Wiederherstellungsszenario bereitstellen. Vollständige Sicherungen, die mit dem Plug-in generiert werden, können zum Wiederherstellen einer ganzen Instanz, einzelner oder mehrerer Datenbanken und einzelner oder mehrerer Tabellen verwendet werden.

Die Protokolle für das Löschen von Binärdateien nach vollständiger oder inkrementeller Sicherung stellen sicher, dass Binärprotokolle nach einer vollständigen oder inkrementellen Sicherung gelöscht werden. Diese Option ist standardmäßig aktiviert, wenn das Plug-in mit einer standardmäßigen MySQL-Serverkonfiguration verwendet wird, die Option MySQL-Replikation aktivieren deaktiviert und die Option Zeitpunktwiederherstellung aktivieren aktiviert ist. Sie ist deaktiviert, wenn das Plug-in mit einem Cluster verbunden ist. Sie müssen das Löschen der Binärprotokolle außerhalb des Plug-ins verwalten.

WICHTIG: In einer gemischten Umgebung, in der ein NetVault Backup Server sowohl geclusterte als auch standardmäßige MySQL-Server verwaltet, dürfen Sie keine Sicherungsoptionssätze, die für einen standardmäßigen MySQL-Server erstellt wurden, für ein MySQL-basiertes Cluster verwenden.

Wenn Sie die Option Binärprotokolle löschen … nicht auswählen, verfolgt das Plug-in das letzte gesicherte Protokoll in seiner Konfigurationsdatei. Sie können Binärprotokolle nach eigenem Ermessen manuell löschen. Wenn Sie beispielsweise eine MySQL-Replikationsumgebung verwenden, in der Sie keine Binärprotokolle von der Master-Instanz löschen möchten, bis sie auf die Slave-Instanz repliziert wurden, sind Sie dafür verantwortlich, die Binärprotokolle manuell zu löschen.

Eine inkrementelle Sicherung sichert die Transaktionsprotokolle, die seit der letzten vollständigen oder inkrementellen Sicherung generiert wurden, gefolgt von den Binärprotokollen. Da die Binärprotokolle auf einer Instanz basieren, werden die Transaktionsprotokolle für jede Datenbank gesichert und als Einheit gelöscht.

Inkrementelle Sicherungen sind bei der Reduzierung von Datenverlusten nach einem Medienausfall oder Datenbeschädigung unerlässlich. Sie können inkrementelle Sicherungen verwenden, um zu einem Zeitpunkt vor und nach einer Datenbeschädigung wiederherzustellen, z. B. falsche Aktualisierung oder gelöschte Tabelle. Im Gegensatz zu kompletten Sicherungen erfordern inkrementelle Sicherungen keinen schreibgeschützten Zugriff während der Sicherung.

Inkrementelle MySQL-Sicherungen erfordern, dass Sie die MySQL-Instanz mit der Option „-log-bin“ starten, wodurch das Binärprotokoll aktiviert wird. Dieses Verfahren ist unter „Aktivieren des binären Protokolls auf dem MySQL-Server (nur Standard/Community-Option)“ beschrieben. Weitere Informationen finden Sie im MySQL-Referenzhandbuch im Abschnitt zu Binärprotokollen.

Wie bereits zuvor beschrieben, stellt die Option Binärprotokolle nach vollständiger oder inkrementeller Sicherung löschen sicher, dass Binärprotokolle nach einer vollständigen oder inkrementellen Sicherung gelöscht werden. Wenn Sie diese Option nicht verwenden, verfolgt das Plug-in das letzte gesicherte Protokoll in der Konfigurationsdatei und Sie können Binärprotokolle nach eigenem Ermessen manuell löschen.

Bei einer differenziellen Sicherung werden die Transaktionsprotokolle gesichert, die seit der letzten vollständigen oder inkrementellen Sicherung erstellt wurden. Die binären Protokolle werden jedoch nicht nach Abschluss der Sicherung gelöscht. Daher erhöht sich für nachfolgende differenzielle Sicherungen Größe und Dauer. Die Größe und Dauer erhöhen sich, da jede Sicherung dieses Typs die Binärprotokolle enthält, die in der vorherigen differenziellen Sicherung ebenfalls enthalten waren, und die Binärprotokolle, die seit der letzten differenziellen Sicherung generiert wurden. Wenn beispielsweise am Sonntag eine vollständige Sicherung durchgeführt wurde mit geplanten differentiellen Sicherungen von Montag bis Samstag, enthält die differenzielle Sicherung von von Montag die Binärprotokolle, die seit der kompletten Sicherung am Sonntag generiert wurden, während die differenzielle Sicherung von Dienstag die am Montag und Dienstag generierten Protokolle umfasst. Die differenzielle Sicherung von Mittwoch enthält die Binärprotokolle für Montag, Dienstag und Mittwoch usw.

Ähnlich wie bei einer inkrementellen Sicherung kann auch die differenzielle Sicherung verwendet werden, um Datenverlust nach einem Medienausfall oder einer Datenbeschädigung zu reduzieren, und zwar mit der Möglichkeit, zu einem Zeitpunkt vor oder nach dem Ausfall oder der Beschädigung wiederherzustellen. Im Gegensatz zu einer vollständigen Sicherung benötigt eine differenzielle Sicherung keinen schreibgeschützten Zugriff während der Sicherung.

Differenzielle Sicherungen erfordern, dass Sie die MySQL-Instanz mit der Option „-log-bin“ starten, wodurch das Binärprotokoll aktiviert wird. Dieses Verfahren ist unter „Aktivieren des binären Protokolls auf dem MySQL-Server (nur Standard/Community-Option)“ beschrieben. Weitere Informationen finden Sie im MySQL-Referenzhandbuch im Abschnitt zu Binärprotokollen.

Da inkrementelle Sicherungen die Binärprotokolle nach der Sicherung löschen, sind nachfolgende inkrementelle Sicherungen schneller, weil nur die Binärprotokolle erstellt wurden, die seit der letzten inkrementellen Sicherung erstellt wurden. Wiederherstellungssequenzen, die inkrementelle Sicherungen verwenden, erfordern jedoch, dass jede inkrementelle Sicherung zwischen der vollständigen Sicherung und dem Fehlerpunkt in Folge wiederhergestellt werden muss. Dieser Prozess kann zu einer längeren Wiederherstellung und einem höheren Aufwand für den DBA führen, um mehrere Wiederherstellungsjobs zu initiieren.

Da differenzielle Sicherungen die Binärprotokolle nach der Sicherung nicht löschen, dauert jede nachfolgende differenzielle Sicherung länger, da alle binären Protokolle seit der letzten vollständigen Sicherung in der Sicherung enthalten sind. Wiederherstellungssequenzen, die differenzielle Sicherungen verwenden, erfordern dafür jedoch nur, dass 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 Gesamt-Sicherungs- und Wiederherstellungsverfahren für eine vollständige Datenbank auswirken. Beispielsweise können Sicherungen eine Quelle für eine Testumgebung oder als erste Synchronisierung für eine Replikations-Slave-Instanz sein. Einzelne Datenbank-/Tabellenkopien werden nur für diese speziellen Zwecke entwickelt, da Sie es Ihnen ermöglichen, eine MySQL-Umgebung „kopieren“ zu können. „Nur Kopie“-Sicherungen sind unabhängig von einer festgelegten Reihenfolge von Sicherungen und wirken sich nicht auf die Wiederherstellbarkeit von vollständigen, inkrementellen oder differenziellen Sicherungen aus. Sie können jedoch nicht als Ersatz für eine vollständige Sicherung verwendet werden.

Wie für Sicherungen einzelner Datenbank-/Tabellenkopien beschrieben, wird die Option „Gesamte Datenbank-Kopiesicherung“ nur für spezielle Zwecke verwendet, da Sie eine Kopie der ausgewählten MySQL-Datenbanken erstellt, einschließlich aller entsprechenden InnoDB-Tabellen der gewählten Datenbanken. „Kopie“-Sicherungen sind unabhängig von einer festgelegten Reihenfolge von Sicherungen und wirken sich nicht auf die Wiederherstellbarkeit von vollständigen, inkrementellen oder differenziellen Sicherungen aus. Sie können jedoch nicht als Ersatz für eine vollständige Sicherung verwendet werden.

Für jede ausgewählte Datenbank, selbst wenn nur eine Tabelle der Datenbank ausgewählt ist, wird mit der Option „Gesamte Datenbankkopie sichern“ die gesamte Datenbank gesichert. Mit dieser Option können Sie einzelne Datenbanken für die Sicherung auswählen, aber nicht einzelne Tabellen. Darüber hinaus unterstützt diese Option nur die Sicherung von InnoDB-Tabellen.

Mit der Option „Nur einzelne Datenbank-/Tabellenkopien sichern“ können Sie einzelne Datenbanken und einzelne Tabellen auswählen und Sie können InnoDB- und MyISAM-Tabellen in die Sicherung aufnehmen. Sicherungen werden jedoch in der Regel schneller abgeschlossen, wenn Sie die Option „Gesamte Datenbankkopie sichern“ statt der Option „Nur einzelne Datenbank-/Tabellenkopien sichern“ verwenden.

Überprüfen der Sicherungstypen für MySQL Enterprise Backup

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

In einer vollständigen Sicherung für die Option MySQL Enterprise Backup verwendet das Plug-in das Dienstprogramm mysqlbackup oder das entsprechende NetVault Backup Skript, um jedes ausgewählte Datenbankobjekt in der Instanz zu sichern. Vollständige Sicherungen bilden die Grundlage für jede Sicherungsstrategie, da sie den Ausgangspunkt für fast jedes Wiederherstellungsszenario bereitstellen. Vollständige Sicherungen, die mit dem Plug-in generiert werden, können zum Wiederherstellen einer ganzen Instanz, einzelner oder mehrerer Datenbanken und einzelner oder mehrerer Tabellen verwendet werden.

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 in der Tabelle seit der letzten vollständigen oder inkrementellen Sicherung etwas geändert wurde.

Wenn Sie eine TTS-Sicherung durchführen, führt das Plug-in eine komplette Sicherung durch 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 der Option innodb_file_per_table erstellt wurden, sind in der Sicherung enthalten.

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

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation