NetVault Plug-in for MySQL 12.2


	WICHTIG: Quest empfiehlt dringend, Sonderzeichen aus Datenbanknamen zu entfernen. Wenn ein Datenbankname eines der folgenden Zeichen enthält, kann das Plug-in sie nicht wiederherstellen: $ ^ = @ # % + Da Sicherungsdaten direkt vom MySQL Server an den NetVault Backup Media Manager gestreamt werden, kann die Verwendung von vorangestellten Zeichen als Sequenzbefehl interpretiert werden, der sich auf die Integrität der Sicherungsdaten auswirkt.

Wichtige Hinweise für MySQL Standard/Community

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

•

Alle Zeichen außer alphanumerischen Zeichen und Unterstrichen gelten als Sonderzeichen.

•

Verwenden des MIXED-Binärprotokollierungsformats

Alle Zeichen außer alphanumerischen Zeichen und Unterstrichen gelten als Sonderzeichen.

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

•

Alle Tabellentypen mit Ausnahme von MyISAM werden gesichert, auch wenn der Datenbankname Bindestriche enthält. Diese Sicherungen werden durchgeführt, da für diese Tabellentypen immer der Befehl „mysqldump“ verwendet wird.

•

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.

Bei früheren Versionen versuchte das Plug-in, das Vorhandensein des Datenbankverzeichnisses zu überprüfen, protokollierte eine Warnmeldung, wenn dies nicht möglich war, und setzte die Sicherung der nächsten Datenbank fort. Die Sicherung wurde mit Warnungen abgeschlossen und erstellte einen Speichersatz, der alle anderen Datenbanken enthielt.

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“:

[MySql:ValidateDatabaseDirectory]

Value=TRUE

Wenn Sie dann stattdessen das neue Verhalten verwenden möchten, können Sie den Parameter auf „FALSE“ setzen oder den Parameter aus der Datei nvmysql.cfg entfernen.

•

Die Wiederherstellung einer inkrementellen oder differenziellen Sicherung, die SQL-Anweisungen zum Erstellen von Datenbanken oder Datenbankobjekten enthält, z. B. Tabelle, Ansicht usw., schlägt fehl, wenn eine der Datenbanken oder Datenbankobjekte vorhanden ist. Um dieses Problem zu vermeiden, führen Sie eine Vollsicherung aus, nachdem Sie eine oder mehrere Datenbanken oder Datenbankobjekte erstellt oder gelöscht haben. Dieser Schritt stellt sicher, dass nachfolgende inkrementelle oder differenzielle Sicherungen keine „CREATE“- oder „DROP“-SQL-Anweisungen enthalten.

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.


	WICHTIG: Inkrementelle und differenzielle Sicherungsaufträge werden mit einer Warnung abgeschlossen, wenn das MIXED-Binärprotokollierungsformat verwendet wird.

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.

-bash-$ mysql

mysql> insert into my_database.my_table (C1,C2) values(1,now());

Query OK, 1 row affected (0.01 sec)

•

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.

-bash-$ mysql

mysql> use mysql

Database changed

mysql> insert into my_database.my_table (C1,C2) values(2,now());

Query OK, 1 row affected (0.04 sec)

•

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.

-bash-$ mysql

mysql> use my_database

Database changed

mysql> insert into my_database.my_table (C1,C2) values(3,now());

Query OK, 1 row affected (0.04 sec)

•

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.

-bash-$ mysql

mysql> use mysql

Database changed

mysql> insert into my_database.my_table (C1,C2) values(4,now());

Query OK, 1 row affected (0.01 sec)

mysql> use my_database

Database changed

mysql> insert into my_database.my_table (C1,C2) values(5,now());

Query OK, 1 row affected (0.04 sec)

Wichtige Hinweise für MySQL Enterprise Backup

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

•

MySQL empfiehlt die Verwendung von InnoDB-Tabellen für kritische Daten, da der Sicherungsprozess schneller ist und die Funktionen für Zuverlässigkeit und Skalierbarkeit vorteilhaft sind. Mit MySQL Enterprise Backup können Sie verschiedene Arten von MySQL-Tabellen sichern und es ist für die Sicherung von InnoDB-Tabellen optimiert. Mit dieser Option wird ein Hotbackup aller InnoDB-Tabellen durchgeführt. Da während der Ausführung der Datenbank Hotbackups durchgeführt werden, werden laufende Datenbankvorgänge nicht angehalten. Außerdem werden alle Datenbankänderungen berücksichtigt, die während des Sicherungsprozesses vorgenommen wurden. Dieses Verhalten ist wichtig, wenn Ihre Umgebung erfordert, dass die Datenbank online bleibt und gleichzeitig ihr Wachstum unterstützt, was sich auf die Zeit auswirkt, die für die Durchführung einer Sicherung erforderlich ist.

•

Wenn Sie diese Option verwenden, werden die MyISAM-Tabelle und andere Tabellen ohne InnoDB zuletzt gesichert, und zwar mit einem Warmbackup. Bei einem Warmbackup wird die Datenbank weiterhin ausgeführt, die Tabellen sind jedoch auf schreibgeschützten Zugriff eingestellt, während die Sicherung abgeschlossen wird.

•

Wenn Sie sicherstellen möchten, dass der Großteil Ihrer Daten während der Hotbackup-Phase gesichert wird, sollten Sie InnoDB als Standardspeichermodul für neue Tabellen festlegen und vorhandene Tabellen in das InnoDB-Speichermodul konvertieren. In MySQL Server 5.5 und höher ist InnoDB die Standardeinstellung.

•

Eine inkrementelle Sicherung ist in erster Linie für InnoDB-Tabellen und Nicht-InnoDB-Tabellen gedacht, die schreibgeschützt sind oder selten aktualisiert werden. Bei Nicht-InnoDB-Dateien wird die gesamte Datei eingeschlossen, wenn sie seit der letzten Sicherung geändert wurde.

•

Bei Verwendung des Plug-ins werden alle InnoDB-Tabellen in einer MySQL-Instanz gesichert, wenn eine der folgenden Bedingungen erfüllt ist:

•

Nur Tabellen werden explizit für die Sicherung ausgewählt und keine der Tabellen ist vom Typ bzw. Speichermodul „InnoDB“.

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.

•

Einige oder alle Datenbanken werden für die Sicherung ausgewählt und alle zugehörigen InnoDB-Tabellen werden von der Sicherung ausgeschlossen.

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.

Wenn Sie die mysqldump-basierte Option verwenden, wird der Befehl für jede Tabelle, jeden Trigger und jede gespeicherte Prozedur einmal ausgeführt. Hotbackups werden nicht unterstützt.

•

Wie oft sollten Vollsicherungen angesichts der Tatsache durchgeführt werden, dass während Vollsicherungen in der gesamten Instanz schreibgeschützter Zugriff erforderlich ist?

•

Was ist wichtiger: schnellere Sicherungen oder schnellere Wiederherstellungen?

•

Wie hoch ist die maximale Menge an Daten, die verloren gehen dürfen?

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

•

Die Sicherungstypen für MySQL Enterprise Backup im Überblick

•

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

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:

•

Vollsicherung

•

Inkrementelle Sicherung

•

Differenzielle Sicherung

•

Individuelle Datenbank-/kopierbasierte Tabellensicherung

•

Kopiesicherung der gesamten Datenbank

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.

Vollsicherungen

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.

Inkrementelle Sicherungen:

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.

Differenzielle Sicherungen:

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 .

Inkrementelle im Vergleich zu differenziellen Sicherungen

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.

Individuelle Datenbank-/kopierbasierte Tabellensicherungen

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.

Kopiesicherungen der gesamten Datenbank

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.


	WICHTIG: Sie können diese Option nur verwenden, wenn alle Tabellen für die ausgewählten Datenbanken InnoDB-Tabellen sind.

Individuelle Datenbank-/kopierbasierte Tabellensicherungen im Vergleich zu Kopiesicherungen der gesamten Datenbank

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.

Vollsicherungen

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.

Inkrementelle Sicherungen

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.

TTS-Sicherungen (Transportable Tablespace; Portabler Tabellenbereich)

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


	WICHTIG: Quest empfiehlt nachdrücklich, dass Sie TTS-Sicherungen nur als eigenständige Sicherungen erstellen, getrennt von Ihrem Sicherungsplan. Da es sich bei TTS-Sicherungen um Teilsicherungen handelt, können Sie diese weder als Ersatz für eine vollständige oder eine inkrementelle Sicherungsstrategie verwenden noch für eine Notfallwiederherstellung.

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

•

TTS-Sicherungen werden nur in MySQL Server 5.6 und höher unterstützt.

•

Nur InnoDB-Tabellen sind in der Sicherung enthalten.

•

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

•

Die Sicherung einer partitionierten Tabelle schlägt fehl, wenn die Partition in einem gemeinsam genutzten Tabellenbereich erstellt wurde.

•

Die Sicherung schließt das Binär- oder Relaisprotokoll aus.

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.