Kurze Analyse der geplanten MySQL-Sicherungsaufgaben

Einführung

Um Datenverlust in einer Produktionsumgebung zu vermeiden, wird die Datenbank normalerweise regelmäßig gesichert. Der Linux-Befehl crontab kann uns dabei helfen, die Datenbank regelmäßig zu sichern. Werfen wir zunächst einen kurzen Blick auf den crontab-Befehl. Wenn Sie wissen, wie es geht, fahren Sie bitte mit dem nächsten Inhalt fort: MySQL-Backup.
Die MySQL-Datenbank in diesem Artikel ist in einem Docker-Container installiert, der als Beispiel zur Erklärung dient. Wenn es nicht im Docker-Container installiert ist, können Sie auch darauf verweisen.

Contab geplante Aufgaben

Verwenden Sie crontab -e, um unsere geplanten Aufgaben zu schreiben.

0 5 * * 1 [Befehl]

Die ersten fünf Zahlen stehen jeweils für Minute, Stunde, Tag, Monat und Woche und command ist Ihr Ausführungsbefehl.
Wenn Sie eine geplante Aufgabe jeden Tag um 20:00 Uhr ausführen müssen, können Sie sie wie folgt schreiben

0 8 * * * [Befehl]

Erweiterungen:

• crontab -l kann Ihre geplanten Aufgaben anzeigen
• crontab -r löscht alle geplanten Aufgaben für den aktuellen Benutzer

MySQL-Sicherung

Schneller Einstieg

Hier ist meine MySQL-Datenbank ein Docker-Container. Wenn Sie jeden Abend um 8 Uhr eine geplante Aufgabe ausführen müssen, können Sie dies wie folgt schreiben.
Führen Sie zuerst den Befehl crontab -e aus.

0 8 * * * docker exec mysql_container mysqldump -uroot -proot_password Datenbankname > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql

mysql_container ist der Name Ihres Datenbankcontainers
mysqldump ist ein Befehl zum Exportieren von Daten aus einer MySQL-Datenbank
-u gibt das Root-Konto an
-p gibt das Root-Passwort ein
database_name Der Name der zu sichernden Datenbank
/var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql-Sicherungsdatei, gefolgt vom Dateinamenformat

Wenn Sie keine Anforderungen haben und nur ein Backup erstellen möchten, kann Ihnen der obige Befehl dabei helfen, geplante Backups durchzuführen.

Kleine Fallstricke: Beim Sichern von MySQL habe ich mit Kommandos wie docker exec -it mysqldump ... ein bash -Skript erstellt. Da der Parameter -i eine interaktive Bedeutung hat, wurden beim Ausführen von geplanten Tasks in crontab keine Daten in sql Datei ausgegeben. Fügen Sie daher den Parameter -i nicht hinzu, wenn Sie crontab verwenden, um den Docker-Container regelmäßig zu sichern.

Crontab-Optimierung

Ich empfehle nicht, die auszuführenden Befehle direkt in crontab -e zu schreiben. Wenn es zu viele Aufgaben gibt, wird die Datei unübersichtlich.
Es wird empfohlen, den Befehl zur Datenbanksicherung in ein bash -Skript zu schreiben. Rufen Sie es einfach in crontab auf, beispielsweise: Erstellen Sie eine Datei /var/backups/mysql/mysqldump.sh mit folgendem Inhalt

docker exec mysql_container mysqldump -uroot -pmypassword Datenbankname > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql

Machen Sie dann die Datei für den aktuellen Benutzer ausführbar:

chmod 711 /var/backups/mysql/mysqldump.sh

Führen Sie den Befehl crontab -e aus und ändern Sie ihn wie folgt:

0 20 * * * /var/backups/mysql/mysqldump.sh

Dann ist dies standardisierter.

MySQL-Backup-Optimierung

Da SQL-Dateien relativ groß sind, werden sie im Allgemeinen komprimiert, da sonst der Speicherplatz zu groß wird.
Vorausgesetzt, Sie haben die oben beschriebene Crontab-Optimierung durchgeführt, können wir das Skript mysqldump.sh wie folgt ändern:

exportiere mysqldump_date=$(Datum +%Y%m%d_%H%M%S) && \
docker exec mysql_container mysqldump -uroot -pmypassword Datenbankname> /var/backups/mysql/$mysqldump_date.sql && \
gzip /var/backups/mysql/$mysqldump_date.sql
finde /var/backups/mysql/ -name "*.sql" -mtime +15 -exec rm -f {} \;

export definiert eine Variable mysqldump_date im System zur Verwendung in Backup- und Komprimierungsbefehlen
gzip ist ein Komprimierungsbefehl. Standardmäßig wird die Quelldatei nach der Komprimierung gelöscht und in eine .gz-Datei komprimiert.
Der Befehl find ... bedeutet, /var/backups/mysql/ nach allen Dateien zu durchsuchen, die vor 15 Tagen erstellt wurden (-mtime +15 ) und die Dateinamenerweiterung .sql haben, und den Löschbefehl -exec rm -f {} \; auszuführen. Die allgemeine Bedeutung lautet: MySQL-Sicherungsdateien werden nur 15 Tage lang aufbewahrt. Löschen Sie alle Beiträge, die älter als 15 Tage sind.

Datenwiederherstellung

Wenn Sie versehentlich drop database ausführen, bleiben Sie ruhig. Wir müssen zuerst die Datenbank dort erstellen, wo die Datenbank gelöscht wurde.

>mysql erstelle Datenbank Datenbankname;

Stellen Sie dann die aktuellste Sicherung wieder her. Befehl zum Wiederherstellen der Sicherung:

docker exec -i mysql_container mysql -uroot -proot_password Datenbankname < /var/backups/mysql/20200619_120012.sql

Obwohl die Daten der Sicherungsdatei wiederhergestellt wurden, haben wir die Daten nach dem Sicherungszeitpunkt nicht wiederhergestellt.
Wenn Sie beispielsweise um 20:00 Uhr eine geplante Sicherung durchführen, die Datenbank jedoch um 21:00 Uhr löschen, werden die Daten in der Stunde zwischen 20:00 und 21:00 Uhr nicht gesichert. Zu diesem Zeitpunkt sollte das Binlog-Protokoll verwendet werden.

binlog

Binlog ist ein Archivprotokoll von MySQL, das die Logik der Datenänderung aufzeichnet, z. B. das Hinzufügen von 1 zum Geldfeld der Zeile mit der ID = 3.
Loggen Sie sich zunächst bei mysql ein und fragen Sie ab, wie viele Binlog-Dateien aktuell vorhanden sind:

> MySQL zeigt Binärprotokolle an;
+--------------+--------------+-----------+
| Protokollname | Dateigröße | Verschlüsselt |
+--------------+--------------+-----------+
| binlog.000001 | 729 | Nein |
| binlog.000002 | 1749 | Nein |
| binlog.000003 | 1087 | Nein |
+--------------+--------------+-----------+

Zeigen Sie das aktuell geschriebene Binärprotokoll an.

mysql> Masterstatus anzeigen\G;

Erzeugt eine neue Binärprotokolldatei. Alle nachfolgenden MySQL-Operationen werden in die neue Binärprotokolldatei geschrieben. Normalerweise wird dieser Befehl beim Wiederherstellen von Daten zuerst ausgeführt.

mysql> Protokolle leeren

Binlog-Protokoll anzeigen

mysql> Binlog-Ereignisse in „binlog.000003“ anzeigen;

Tipps: Fügen Sie beim Initialisieren des MySQL-Containers den Parameter --binlog-rows-query-log-events=ON hinzu. Oder ändern Sie die Datei /etc/mysql/my.cnf im Container, fügen Sie den Parameter binlog_rows_query_log_events=ON hinzu und starten Sie dann den MySQL-Container neu. Dadurch wird das ursprüngliche SQL zur Binärprotokolldatei hinzugefügt.

Daten wiederherstellen

Nehmen Sie die Passage aus dem obigen Beispiel zurück.

Die geplante Sicherung wird um 20:00 Uhr durchgeführt, die Datenbank wird jedoch um 21:00 Uhr gelöscht. Daher werden die Daten zwischen 20:00 und 21:00 Uhr nicht gesichert. .

Wechseln Sie zunächst nach dem Aufrufen des MySQL-Containers in das Verzeichnis /var/lib/mysql und überprüfen Sie das Erstellungsdatum der Binlog-Datei

cd /var/lib/mysql
ls -l
...
-rw-r----- 1 mysql mysql 729 19. Juni 15:54 binlog.000001
-rw-r----- 1 mysql mysql 1749 19. Juni 18:45 binlog.000002
-rw-r----- 1 mysql mysql 1087 19. Juni 20:58 binlog.000003
...

Aus dem Dateidatum können wir ersehen, dass es sich um die Uhrzeit 21.06.2020 handelt und die letzte Aktualisierungszeit der Datei binlog.000002 18:45 Uhr ist. Daher muss das Backup um 20:00 Uhr die Daten von binlog.000002 enthalten.
Das letzte Aktualisierungsdatum von binlog.000003 ist 20:58 Uhr, daher müssen wir folgende Daten wiederherstellen: das vollständige Backup um 20:00 Uhr + die Daten vor 20:00 Uhr von binlog.000003 – die Uhrzeit, zu der der Befehl zum Löschen der Datenbank ausgeführt wurde.

Format des Wiederherstellungsbefehls:

mysqlbinlog [Optionen] Datei | mysql -uroot -proot_password Datenbankname

Allgemeine Parameter von mysqlbinlog:

--start-datetime Startzeit, Format 2020-06-19 18:00:00
--stop-datetime Endzeit, gleiches Format wie oben
--start-position Startposition (Binlog-Datei muss angezeigt werden)
--stop-position Endposition, wie oben
...

Bevor Sie die Sicherungsdaten und Binlog-Daten wiederherstellen, wird empfohlen, sich bei MySQL anzumelden und flush logs auszuführen, um ein neues binlog -Protokoll zu generieren, damit Sie sich auf die wiederherzustellende binlog Datei konzentrieren können.
Zuerst müssen wir das Binlog-Protokoll überprüfen, um zu sehen, wo drop database ausgeführt wurde:

mysql> Binlog-Ereignisse in „binlog.000003“ anzeigen;
+------------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------------------------------------------+
| Logname | Pos | Ereignistyp | Server-ID | End_log_pos | Info |
+------------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------------------------------------------+
| binlog.000003 | 4 | Format_desc | 1 | 125 | Serverversion: 8.0.20, Binlogversion: 4 |
| binlog.000003 | 125 | Vorherige_gtids | 1 | 156 | |
| binlog.000003 | 156 | Anonymous_Gtid | 1 | 235 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| binlog.000003 | 235 | Abfrage | 1 | 318 | BEGIN |
| binlog.000003 | 318 | Rows_query | 1 | 479 | # INSERT INTO `product_category` SET `name` = 'Bettwäsche' , `create_time` = 1592707634 , `update_time` = 1592707634 , `lock_version` = 0 |
| binlog.000003 | 479 | Table_map | 1 | 559 | table_id: 139 (Hotelserver.Produktkategorie) |
| binlog.000003 | 559 | Zeilen schreiben | 1 | 629 | Tabellen-ID: 139 Flags: STMT_END_F |
| binlog.000003 | 629 | Xid | 1 | 660 | COMMIT /* xid=2021 */ |
| binlog.000004 | 660 | Anonymous_Gtid | 1 | 739 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| binlog.000004 | 739 | Abfrage | 1 | 822 | Datenbank hotel_server löschen /* xid=26 */ |
+---------------+-----+----------------+-----------+-------------+-------------------------+--------------------------------------------------------------------------------------------------------------------------

Dem obigen Protokoll können wir entnehmen, dass der Vorgang drop database bei End_log_pos= 822 ausgeführt wurde. Der Bereich für die binlog liegt also 2020-06-19 20:00:00 - 660 . Warum 660? Da sich das Commit der vorherigen Transaktion von drop database an Position 660 befindet, lautet der Befehl wie folgt:

mysqlbinlog --start-datetime=2020-06-19 20:00:00 --stop-position=660 /var/lib/mysql/binlog.000003 | mysql -uroot -proot_password Datenbankname

Wenn Ihr Bereich die Position 822 umfasst, wird der Befehl „ drop database für Sie ausgeführt. Wenn Sie es nicht glauben, probieren Sie es aus?
Nach der Ausführung des obigen Befehls werden Ihre Daten in den Zustand vor drop database zurückversetzt! Glücklich oder nicht, aufgeregt oder nicht!

Zusammenfassen

Weil die geplante Sicherung von MySQL in der Produktionsumgebung eine notwendige Aufgabe ist. Es wird sehr häufig verwendet. Ich konnte es kaum erwarten, einen Blog zu schreiben. Natürlich bin ich auch für die Hilfe meiner Kollegen sehr dankbar. Das Schreiben dieses Artikels dauerte drei Tage, da ich ständig herumprobiere und Fehler mache und den Artikel ständig aktualisiere. Vermeiden Sie das Aufschreiben falscher Wissenspunkte. Wenn Ihnen das hilft, folgen Sie mir bitte! Danke.

Oben finden Sie eine kurze Analyse der Details der geplanten MySQL-Sicherungsaufgabe. Weitere Informationen zur geplanten MySQL-Sicherungsaufgabe finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!