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 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. |
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.
WICHTIG: Inkrementelle und differenzielle Sicherungsjobs werden mit einer Warnung abgeschlossen, wenn das gemischte Binärprotokollformat verwendet wird. |
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:
• |
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. |
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 MySQL Standard/Community verwenden, verwendet das Plug-in mysqldump, um die folgenden Sicherungstypen bereitzustellen:
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.
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.
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 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.
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.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center