So verwenden Sie mysqldump für vollständige und zeitpunktbezogene Sicherungen

Mysqldump wird für logische Backups in MySQL verwendet. Obwohl es nicht schnell ist, ist es sehr flexibel und hat viele Funktionen. Es ist definitiv ein mächtiges Werkzeug, wenn es flexibel verwendet wird.

Lassen Sie uns zunächst über eine Frage nachdenken: Warum muss MySQL gesichert werden? Der Hauptgrund ist die Datensicherheit. Wenn beispielsweise die Hauptdatenbank abstürzt und die Daten versehentlich gelöscht werden, ist eine vollständige Sicherung sehr wichtig.

Soll eine vollständige Sicherung der primären oder der sekundären Datenbank durchgeführt werden?

1: Aus der Hauptbibliothek

Die Hauptdatenbank ist wichtiger, aber tatsächlich hat die Sicherung keine Auswirkungen auf die Datenbank

mysqldump --host= --user= --password= --single-transaction --master-data=1 --flush-logs --databases >~/db.log

Der Parameter --single-transaction ermöglicht das konsistente Lesen ohne Sperren der Tabelle, so dass Datenaktualisierungen beim Backup nicht beeinträchtigt werden.

Es wird der konsistente Zustand der Datenbank zum Zeitpunkt der Ausgabe von START TRANSACTION gesichert, ohne Anwendungen zu blockieren.

Da durch konsistentes Lesen die Position des Koordinatenpunkts garantiert werden kann, kann auch bei langer Sicherungszeit der richtige Synchronisationsstandort ermittelt werden.

Während ein Einzeltransaktionsdump ausgeführt wird, um eine gültige Dump-Datei sicherzustellen (korrekter Tabelleninhalt und binäre Log-Koordinaten)

Der Parameter --master-data ist ebenfalls sehr wichtig. Die exportierten Anweisungen enthalten die Anweisung CHANGE MASTER TO, einschließlich der Binärdatei und des mit der Sicherungsanweisung synchronisierten Speicherorts.

Verwenden Sie diese Option, um einen Master-Replikationsserver zu dumpen und eine Dump-Datei zu erstellen, die verwendet werden kann, um einen anderen Server als Slave des Masters einzurichten. Dadurch enthält die Dump-Ausgabe eine CHANGE MASTER TO-Anweisung, die die Binärlog-Koordinaten (Dateiname und Position) des gedumpten Servers angibt. Dies sind die Master-Server-Koordinaten, von denen aus der Slave mit der Replikation beginnen soll, nachdem Sie die Dump-Datei in den Slave geladen haben.

--flush-logs erzwingt die Neugenerierung einer neuen Binärdatei, was die Wiederherstellung erleichtert.

2: Aus der Sekundärbibliothek

Es erscheint sicherer, von der sekundären Bibliothek aus zu sichern.

mysqldump --host=--user= --password= --dump-slave=1 --flush-logs --apply-slave-statements --include-master-host-port --databases >~/db.log;

Die Parameter --dump-slave und --master-data sind sehr ähnlich:

Diese Option ist ähnlich wie --master-data, außer dass sie zum Dumpen eines Replikations-Slave-Servers verwendet wird, um eine Dump-Datei zu erstellen, die zum Einrichten eines anderen Servers als Slave verwendet werden kann, der denselben Master wie der gedumpte Server hat. Sie bewirkt, dass die Dump-Ausgabe eine CHANGE MASTER TO-Anweisung enthält, die die Binärlog-Koordinaten (Dateiname und Position) des Masters des gedumpten Slaves angibt. Dies sind die Master-Server-Koordinaten, von denen aus der Slave mit der Replikation beginnen soll.

Denken Sie daran, dass die Bin-Log-Koordinaten der primären Bibliothek (nicht der Backup-Bibliothek) abgerufen werden.

—dump-slave bewirkt, dass die Koordinaten des Masters und nicht die des gedumpten Servers verwendet werden

Die ausgegebene Anweisung enthält die Position, von der aus die Replikation oder die zeitpunktbezogene Wiederherstellung gestartet werden soll.

--apply-slave-statements schließt die Start- und Stopp-Slave-Anweisungen automatisch in die Dump-Anweisung ein. --include-master-host-port schließt die Verbindungsinformationen der Masterbibliothek ein.

Eines muss beachtet werden: Selbst mit der Anweisung --single-transaction wird durch --dump-slave die MySQL-Synchronisierung angehalten, d. h. die Daten in der Sicherungsdatenbank hinken der Hauptdatenbank hinterher, sodass das allgemeine automatisierte Skript beim Sichern zuerst die Sicherungsdatenbank entfernt.

Diese Option bewirkt, dass mysqldump den Slave-SQL-Thread vor dem Dump stoppt und danach erneut startet.

3: So führen Sie eine Point-in-Time-Wiederherstellung durch

Ich habe es in der Praxis nicht ausprobiert. Stellen Sie zunächst auf Grundlage der letzten vollständigen Sicherung wieder her und importieren Sie dann nachfolgende Binlog-Dateien (sofern diese noch vorhanden sind). Daher ist es am besten, die Binlog-Anweisungen auch in der sekundären Datenbank zu sichern.

Wenn die Daten versehentlich gelöscht wurden, importieren Sie die Binärprotokollanweisungen vom Sicherungspunkt (--flush-logs wird wirksam) in den heutigen Morgen oder suchen Sie einen sicheren Binärprotokollspeicherort, um sie wiederherzustellen. Wie man „gefährliche Aussagen“ überspringt, ist schwieriger zu kontrollieren.

Oben finden Sie Einzelheiten zur Verwendung von mysqldump für vollständige und zeitpunktbezogene Sicherungen. Weitere Informationen zu mysqldump für vollständige und zeitpunktbezogene Sicherungen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!