Implementierung einer MySQL-Sicherungsstrategie (vollständige Sicherung + inkrementelle Sicherung)

Vor Kurzem musste das Projekt die Datenbankdaten sichern. Durch Konsultation verschiedener Materialien wurde eine Strategie zur Datenbanksicherung entwickelt. Nach einer Woche Fehlerbehebung und Betrieb befindet sie sich nun in einem stabilen Betriebszustand. Jetzt möchte ich meine Ideen teilen und gredn danken.

Entwurfsszenario

1) Die inkrementelle Sicherung wird von Montag bis Samstag um 3:00 Uhr morgens durchgeführt, wobei mysql-bin.00000* in das angegebene Verzeichnis kopiert wird.
2) Für eine vollständige Sicherung verwenden Sie mysqldump, um die gesamte Datenbank zu exportieren. Es wird jeden Sonntag um 3 Uhr ausgeführt und löscht mysq-bin.00000*, das von letzter Woche übrig geblieben ist. Der Sicherungsvorgang von mysql wird dann in der Datei bak.log gespeichert.

Technische Punkte

Mysqldump, mysqlbinlog, crontab

Serverinformationen

Host: centos7; Datenbank: mysql5.7

Vorbereitung

Aktivieren Sie die Binlog-Protokollierung. (1) Erstellen Sie ein neues Verzeichnis und führen Sie aus:

#mkdir /home/mysql
#cd /home/mysql
#mkdir mysql-bin. #Inkrementelles Protokolldateiverzeichnis

(2) Ändern Sie den Benutzer/die Gruppe, zu der es gehört: (Wenn es nicht geändert wird, kann MySQL nicht neu gestartet werden)

#chown -R mysql.mysql mysql-bin 

(3) Ändern Sie die MySQL-Konfigurationsdatei und führen Sie Folgendes aus:

#vim /etc/meine.cnf 

Dabei stellt die Server-ID die ID eines einzelnen Knotens dar. Da es hier nur einen Knoten gibt, kann der ID zufällig eine Nummer zugewiesen werden. Hier wird die ID auf 1 gesetzt. Wenn der Cluster mehrere Knoten enthält, dürfen die IDs nicht identisch sein (bei Versionen unter 5.7 müssen Sie keine Server-ID angeben).
log_bin gibt den Speicherpfad der Binlog-Protokolldatei an. Die Protokolldatei beginnt mit mysql-bin.

(4) Starten Sie MySQL neu und führen Sie aus:

#systemctl mysqld.service neu starten

(5) Zeigen Sie die Protokolldatei an:

#cd /home/mysql/mysql-bin 

(6) Rufen Sie die Datenbank auf und überprüfen Sie den Starteffekt:

#Variablen wie „%log_bin%“ anzeigen; 

Schreiben Sie ein vollständiges Backup-Skript (Mysql-FullyBak.sh).

Wechseln Sie in das Verzeichnis /home/mysql und erstellen Sie ein neues Verzeichnis: mkdir backup
Gehen Sie in das Backup-Verzeichnis und erstellen Sie täglich ein neues Verzeichnis: mkdir backup
Wechseln Sie in das Verzeichnis /home/mysql und führen Sie Folgendes aus:

#vim Mysql-FullyBak.sh

Parameterbeschreibung:
--lock-tables
Sperren Sie die aktuell exportierte Datentabelle, anstatt alle Tabellen in der Datenbank gleichzeitig zu sperren. Diese Option ist nur auf MyISAM-Tabellen anwendbar, wenn die MySQL-Datenbank-Engine verwendet wird. Wenn es sich um eine Innodb-Tabelle handelt, können Sie die Option –single-transaction verwenden.
--flush-logs
Beenden Sie das aktuelle Protokoll und generieren Sie eine neue Protokolldatei.
--delete-master-logs
Löschen Sie alte Protokolle, um Speicherplatz freizugeben. Wenn der Server jedoch als gespiegelter Replikationsmaster konfiguriert ist, ist das Löschen des MySQL-Binärprotokolls mit --delete-master-logs gefährlich, da der Slave-Server den Inhalt des Binärprotokolls möglicherweise nicht vollständig verarbeitet hat. In diesem Fall ist es sicherer, PURGE MASTER LOGS zu verwenden.
-schnell
Diese Option ist beim Exportieren großer Tabellen nützlich. Sie zwingt MySQLdump, den Server abzufragen, um die Datensätze für die Ausgabe direkt abzurufen, anstatt alle Datensätze abzurufen und im Speicher zwischenzuspeichern.
--single-transaction
Diese Option sendet vor dem Exportieren von Daten eine BEGIN-SQL-Anweisung. BEGIN blockiert keine Anwendung und kann die Konsistenz der Datenbank während des Exports sicherstellen. Es gilt nur für Transaktionstabellen wie InnoDB und BDB. Diese Option und die Option --lock-tables schließen sich gegenseitig aus, da Lock-Tables dazu führt, dass alle ausstehenden Transaktionen implizit festgeschrieben werden. Um große Tabellen zu exportieren, verwenden Sie es mit der Option --quick.
–Veranstaltungen
Ereignisse exportieren –master-data=2
Der Parameter --master-data=[0|1|2]
0: Nicht aufzeichnen
1: Aufgezeichnet als CHANGE MASTER-Anweisung
2: Die als Kommentar aufgezeichnete Anweisung CHANGE MASTER mit der Option –master-data=2 zeichnet den Namen der neuen Protokolldatei nach der vollständigen Sicherung im Ausgabe-SQL auf.
Zur Referenz bei zukünftigen Wiederherstellungen enthält die SQL-Ausgabesicherungsdatei beispielsweise Folgendes:
ÄNDERN SIE MASTER IN MASTER_LOG_FILE='MySQL-bin.000002', MASTER_LOG_POS=106;

Schreiben von inkrementellen Backup-Skripten

Wechseln Sie in das Verzeichnis /home/mysql und führen Sie aus:

#vim Mysql-DailyBak.sh 

Crontab für geplante Aufgaben einrichten

(1) Installieren Sie crontab (in centos7 bereits standardmäßig installiert):

#yum crontabs installieren

Service-Bedienungsanleitung:

#/bin/systemctl start crond.service //Dienst starten#/bin/systemctl stop crond.service //Dienst herunterfahren#/bin/systemctl restart crond.service //Dienst neu starten#/bin/systemctl reload crond.service //Neu laden

Konfiguration:

#/bin/systemctl status crond.service //Dienststatus

Automatischen Start hinzufügen:

#chkconfig –level 35 crond ein

(2) Geben Sie in der Kommandozeile ein:

#crontab -e 

Entsprechende Task hinzufügen, speichern und mit wq beenden

#Führen Sie das vollständige Backup-Skript jeden Sonntag um 3:00 Uhr aus 0 3 * * 0 /bin/bash -x /home/mysql/Mysql-FullyBak.sh >/dev/null 2>&1
#Machen Sie inkrementelle Backups von Montag bis Samstag um 3:00 Uhr morgens. 0 3 * * 1-6 /bin/bash -x /home/mysql/Mysql-DailyBak.sh >/dev/null 2>&1

Hinweis: Standardmäßig benachrichtigt crontab den Benutzer per E-Mail, nachdem eine Aufgabe ausgeführt wurde. Um zu vermeiden, dass jedes Mal Nachrichten gesendet werden, fügen Sie /dev/null 2>&1 hinzu.

(3) Geplante Aufgaben anzeigen: #crontab -l

Parameter und Beschreibung:
crontab -u // Cron-Dienst eines Benutzers festlegen. Im Allgemeinen benötigt der Root-Benutzer diesen Parameter, wenn er diesen Befehl ausführt.
crontab -l //Listet die Details des Cron-Dienstes eines Benutzers auf;
crontab -r //Lösche alle Cron-Dienste der Benutzer;
crontab -e //Den Cron-Dienst eines Benutzers bearbeiten;
Beispiel: root kann seine eigenen Cron-Einstellungen einsehen: crontab -u root -l
Beispiel: root löscht die Cron-Einstellungen des Benutzers Fred: crontab -u fred -r
Auffüllen:
(1) Sie können die Datei /etc/crontab, dh vi /etc/crontab, direkt bearbeiten und entsprechende Aufgaben hinzufügen (für die Crontab-Datei des gesamten Systems).
(2) Die Datensätze von Crontab, die geplante Aufgaben ausführen, werden in die Datei /var/log/cron geschrieben, und die Datensätze werden nach Kontonummer unterschieden.

Wiederherstellungsvorgang

Der Wiederherstellungsprozess schreibt auch Protokolldateien. Wenn die Datenmenge groß ist, wird empfohlen, zuerst die Binlog-Funktion zu deaktivieren.
1. Szenario: Angenommen, die Datenbank wird um 9 Uhr morgens angegriffen und die gesamte Datenbank wird gelöscht!
2. Ideen zur Wiederherstellung:
Verwenden Sie die in der vollständigen SQL-Datei, der Binärprotokolldatei und ihren Positionsinformationen aufgezeichnete Anweisung CHANGE MASTER, um den inkrementellen Teil in der Binärprotokolldatei zu finden.
Verwenden Sie den Befehl mysqlbinlog, um die obige Binärprotokolldatei in eine SQL-Datei zu exportieren und die Drop-Anweisung zu entfernen.
Die vollständigen Daten können durch Exportieren der SQL-Datei über die vollständige Sicherungsdatei und die inkrementelle Binärlog-Datei wiederhergestellt werden.
3. Wiederherstellungsschritte:

(1) Dekomprimieren Sie zunächst die letzte vollständige Sicherungsdatei, geben Sie das Sicherungsdateiverzeichnis ein und führen Sie Folgendes aus:

#tar -zxvf XXX.sql.tgz

(2) Um die neu hinzugefügten Binärprotokolldateien nach der vollständigen Sicherung anzuzeigen, führen Sie Folgendes aus:

#grep ÄNDERN XXX.sql 

Wie aus der Abbildung ersichtlich ist, ist dies die Position der Binlog-Datei zum Zeitpunkt der vollständigen Vorbereitung, also Zeile 154 von mysql-bin.000003. Daher sind die Daten in den Binlog-Dateien vor dieser Datei bereits in dieser vollständig vorbereiteten SQL-Datei enthalten.

(3) Stellen Sie die Informationen nach Zeile 154 der Datei mysql-bin.000003 wieder her

Wechseln Sie in das Verzeichnis mysql-bin.000003 und führen Sie es aus (sysecokit ist der Datenbankname).

#mysqlbinlog --start-position=154 --database=sysecokit mysql-bin.000003 | mysql -uroot -p -v sysecokit

(4) Exportieren Sie andere Binlog-Dateien (außer mysql-bin.000003) in SQL-Dateien und führen Sie sie aus (-d gibt die Datenbank an):

#mysqlbinlog -d sysecokit mysql-bin.00000X >00Xbin.sql 

(5) Bearbeiten Sie die neueste 00Xbin.sql mit vim und löschen Sie die Drop-Anweisung
(6) Um die vollständigen Sicherungsdaten wiederherzustellen, führen Sie Folgendes aus:

#mysql -uroot -p < XXX.sql

Beispiel: #mysql -uroot -p < 20180716.sql
(7) Um inkrementelle Daten wiederherzustellen, führen Sie Folgendes aus (syseco ist der Datenbankname):

#mysql -uroot -p syseco<00Xbin.sql

Beispiel: #mysql -uroot -p syseco<004bin.sql
Nachdem nun alles erledigt ist, schauen wir uns die Dateien an, die nach einer Woche Laufzeit generiert wurden:

Dies ist das Ende dieses Artikels über die Implementierung der MySQL-Sicherungsstrategie (vollständige Sicherung + inkrementelle Sicherung). Weitere relevante Inhalte zur MySQL-Sicherungsstrategie finden Sie in den vorherigen Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!