Kapitel 4. Sicherung und Wiederherstellung
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Backup und Wiederherstellung sind zwei unterschiedliche, aber verwandte Konzepte der Datensicherung. Bei der Datensicherung wird eine Kopie der Daten erstellt und an einem sicheren Ort aufbewahrt. Die Wiederherstellung hingegen ist der Prozess der Wiederherstellung von Daten aus einem Backup im Falle eines Datenverlustes. Das Ziel von Backup und Recovery ist es, sicherzustellen, dass die Daten bei Bedarf verfügbar und nutzbar sind.
In diesem Kapitel werden die grundlegenden Konzepte der Sicherung und Wiederherstellung besprochen und anschließend die verschiedenen Arten von Sicherungen erläutert. Außerdem geben wir dir Hinweise zum Erstellen von Backups, zur Wiederherstellung von Backups und zur Verwaltung von Binärprotokollen. Schließlich erfährst du, wie du deine Sicherung und Wiederherstellung verwaltest, um sicherzustellen, dass deine Daten sicher sind und im Katastrophenfall leicht wiederhergestellt werden können.
Bevor wir uns mit den Einzelheiten befassen, ist es wichtig, die grundlegenden Konzepte zu verstehen, die diesen wichtigen Aktivitäten zugrunde liegen. Als DBA musst du sicherstellen, dass deine Daten geschützt sind und im Falle einer Katastrophe wiederhergestellt werden können. Datenverluste können aus verschiedenen Gründen auftreten, z. B. durch Hardwarefehler, menschliches Versagen, Naturkatastrophen oder bösartige Angriffe. Ohne geeignete Sicherungs- und Wiederherstellungsmechanismen kann es viel Zeit, Geld und Mühe kosten, verlorene Daten wiederherzustellen oder sie sogar von Grund auf neu zu erstellen.
Faktoren, die bei der Wahl einer Backup-Strategie zu berücksichtigen sind
Die Wahl einer Backup-Strategie, die den Anforderungen deines Unternehmens entspricht, kann eine Herausforderung sein. Hier sind einige Faktoren, die du berücksichtigen solltest:
- Wiederherstellungspunkt-Ziel (RPO)
-
Der RPO ist das maximale Ausmaß an Datenverlust, das im Falle eines Desasters toleriert werden kann. Ein kürzerer RPO erfordert häufigere Backups oder Point-in-Time-Recovery mit Streaming-Funktionen. Ein RPO von wenigen Sekunden oder 0 kann in der Regel nur mit häufigen Backups oder einer Point-in-Time-Wiederherstellung erreicht werden.
- Ziel für die Wiederherstellungszeit (RTO)
-
Die RTO ist die maximale Zeitspanne, die für die Wiederherstellung nach einer Katastrophe benötigt wird. Eine kürzere RTO erfordert einen schnelleren Wiederherstellungsmechanismus, wie z. B. ein Warm- oder Hot-Standby-System.
- Sicherungsart
-
MySQL unterstützt verschiedene Sicherungsarten, darunter physische Sicherung, logische Sicherung, inkrementelle Sicherung und differenzielle Sicherung. Jede Sicherungsart hat ihre Vor- und Nachteile, und die Wahl der Sicherungsart hängt von den Geschäftsanforderungen ab.
- Speicherort der Sicherung
-
Backups sollten an einem sicheren Ort gespeichert werden, der vom Produktionssystem getrennt ist, um das Risiko eines Datenverlusts zu vermeiden, wenn sowohl das Produktionssystem als auch der Speicherort des Backups von einer Katastrophe betroffen sind.
Zusammenfassend lässt sich sagen, dass wir das gesamte Datenverzeichnis als physisches Backup sichern müssen, einschließlich der binären Logs. Diese Sicherung ist für kritische Situationen, in denen die Instanz oder Umgebung wiederhergestellt werden muss, unerlässlich.
Der Unterschied zwischen physischen und logischen Backups
Logische Backups und physische Backups dienen unterschiedlichen Zwecken und werden unterschiedlich umgesetzt.
Eine logische Sicherung ( ) ist eine Sicherung der logischen Struktur und des Inhalts einer Datenbank, z. B. von Tabellen, Ansichten, gespeicherten Prozeduren, Triggern und Daten. Sie wird erstellt, indem die Daten mit Hilfe von Dienstprogrammen wie mydumper oder dem Instanz-Dump-Dienstprogramm, dem Schema-Dump-Dienstprogramm und dem Tabellen-Dump-Dienstprogramm der MySQL Shell in eine Datei geschrieben werden. Logische Backups sind portabel und können verwendet werden, um eine Datenbank von einem Server auf einen anderen zu migrieren oder um bestimmte Tabellen oder Daten in einer Datenbank wiederherzustellen. Sie können jedoch langsamer erstellt und wiederhergestellt werden als physische Backups.
Ein physisches Backup hingegen ist eine binäre Kopie der MySQL-Datenbankdateien, einschließlich der Daten, Indizes und Tabellenstrukturen. Sie wird erstellt, indem die physischen Dateien direkt vom Server auf eine Speichereinheit oder einen Server kopiert werden. Daher sind sie schneller zu erstellen und wiederherzustellen als logische Backups.
Beide Arten von Backups sind wichtig, um die Verfügbarkeit und Integrität einer MySQL-Datenbank zu gewährleisten. Logische Backups sind nützlich, um Daten zwischen Servern zu migrieren, bestimmte Tabellen oder Daten wiederherzustellen und für langfristige Archivierungszwecke. Physische Backups sind für Disaster Recovery, Backups auf Systemebene und für HA-Lösungen wie die Datenbankreplikation nützlich.
Physische Backups
Die beiden beliebtesten physischen Backups sind MySQL Enterprise Backup und Percona XtraBackup.
MySQL Enterprise Backup
Um eine MySQL-Datenbank zu sichern und wiederherzustellen, kannst du das Tool MySQL Enterprise Backup verwenden. Die Sicherung einer MySQL-Instanz ist entscheidend für die Wiederherstellung der Daten im Falle einer Katastrophe oder eines Verlusts. Es ist wichtig, eine Backup-Strategie zu haben, die die Wiederherstellung der Daten mit minimaler Ausfallzeit ermöglicht.
Um dieses Backup zu konfigurieren, erstelle zum Beispiel ein neues Verzeichnis mit dem Namen backupdir:
[root@mysql80~]#mkdir/backupdir[root@mysql80~]#
Dieser Backup-Befehl weist das MySQL-Backup-Dienstprogramm (mysqlbackup) an, einen Backup-Vorgang mit den folgenden Optionen durchzuführen:
root@mysql80~]#mysqlbackup--user=root --password --backup-image=/backupdir/my.mbi--backup-dir=/backupdir/backup-tmp backup-to-imageMySQLEnterpriseBackupVer8.0.36-commercialforLinuxonx86_64(MySQLEnterprise-Commercial)Copyright(c)2003,2024,Oracleand/oritsaffiliates.OracleisaregisteredtrademarkofOracleCorporationand/oritsaffiliates.Othernamesmaybetrademarksoftheirrespectiveowners.Startingwithfollowingcommandline...mysqlbackup--user=root--password--backup-image=/backupdir/my.mbi--backup-dir=/backupdir/backup-tmpbackup-to-imageIMPORTANT:Pleasecheckthatmysqlbackupruncompletessuccessfully.Attheendofasuccessful'backup-to-image'runmysqlbackupprints"mysqlbackup completed OK!"Enterpassword:24021611:42:48MAININFO:Establishingconnectiontoserver.WARNING:MYSQL_OPT_RECONNECTisdeprecatedandwillberemovedinafutureversion.24021611:42:48MAININFO:NoSSLoptionsspecified.24021611:42:48MAININFO:MySQLserverversionis'8.0.36'24021611:42:48MAININFO:MySQLservercompileosversionis'Linux'24021611:42:48MAININFO:Gotsomeserverconfigurationinformationfromrunningserver.
Anhand des Protokolls kannst du die Konfigurationsoptionen für das Server-Repository und das Backup überprüfen:
24021611:42:48MAININFO:TheMySQLserverhasnoactivekeyring.--------------------------------------------------------------------ServerRepositoryOptions:--------------------------------------------------------------------datadir=/var/lib/mysql/innodb_data_home_dir=/var/lib/mysql/datafile/innodb_data_file_path=ibdata1:12M;ibdata2:10M:autoextendinnodb_log_group_home_dir=/var/lib/mysql/innodb_undo_directory=/var/lib/mysql/innodb_undo_tablespaces=2innodb_buffer_pool_filename=ib_buffer_poolinnodb_page_size=16384innodb_checksum_algorithm=crc32--------------------------------------------------------------------BackupConfigOptions:--------------------------------------------------------------------datadir=/backupdir/backup-tmp/datadirinnodb_data_home_dir=/backupdir/backup-tmp/datadirinnodb_data_file_path=ibdata1:12M;ibdata2:10M:autoextendinnodb_log_group_home_dir=/backupdir/backup-tmp/datadirinnodb_undo_directory=/backupdir/backup-tmp/datadirinnodb_undo_tablespaces=2innodb_buffer_pool_filename=ib_buffer_poolinnodb_page_size=16384innodb_checksum_algorithm=crc32BackupImagePath=/backupdir/my.mbi24021611:42:48MAININFO:Uniquegeneratedbackupidforthisis17080837682941805
Nach Abschluss des Backups erhältst du den Status der Fertigstellung wie im Protokoll angegeben:
24021611:42:49RDR1INFO:Copying/var/lib/mysql/binlog.000012.24021611:42:49RDR1INFO:Completedthecopyofbinlogfiles...24021611:42:49RDR1INFO:Theserverinstanceisunlockedafter0.236seconds.24021611:42:49RDR1INFO:Readingallglobalvariablesfromtheserver.24021611:42:49RDR1INFO:Completedreadingofall640globalvariablesfromtheserver.24021611:42:49RDR1INFO:Writingserverdefaultsfiles'server-my.cnf'and'server-all.cnf'forserver'8.0.36'in'/backupdir/backup-tmp'.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/meta/backup_variables.txt.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/datadir/ibbackup_logfile.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/server-all.cnf.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/server-my.cnf.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/meta/backup_content.xml.24021611:42:49RDR1INFO:Copyingmetafile/backupdir/backup-tmp/meta/image_files.xml.24021611:42:49MAININFO:FullImageBackupoperationcompletedsuccessfully.24021611:42:49MAININFO:Backupimagecreatedsuccessfully.24021611:42:49MAININFO:ImagePath=/backupdir/my.mbi24021611:42:49MAININFO:MySQLbinlogposition:filenamebinlog.000012,position4131.-------------------------------------------------------------ParametersSummary-------------------------------------------------------------StartLSN:37130752LastCheckpointLSN:37130784EndLSN:37204275-------------------------------------------------------------
mysqlbackupcompletedOK![root@mysql80~]#
Hier sind die Details zu den verschiedenen Optionen, die in dem Befehl verwendet werden:
--user-
Gibt den MySQL-Benutzer mit ausreichenden Rechten an, um auf die Datenbank zuzugreifen und sie zu sichern.
--password-
Liefert das Passwort für den in der Option
--userangegebenen MySQL-Benutzer. --backup-image-
Gibt den Namen und den Speicherort der Sicherungsdatei an, die erstellt wird. Diese Datei enthält die gesamte MySQL-Instanz.
--backup-dir-
Gibt das temporäre Sicherungsverzeichnis an, in dem die Sicherungsdateien während des Sicherungsvorgangs gespeichert werden.
backup-to-image-
Gibt die Art der Sicherung an.
Sobald der Befehl ausgeführt wird, beginnt der Sicherungsvorgang und die Sicherungsdateien werden im angegebenen Sicherungsverzeichnis gespeichert. Nach Abschluss des Sicherungsvorgangs wird die Meldung mysqlbackup completed
OK! angezeigt.
Nach Abschluss eines Backups ist es wichtig, die Integrität des Backups zu überprüfen und sicherzustellen, dass alle Daten korrekt gesichert wurden. So kannst du Datenverluste durch beschädigte Backups vermeiden.
Der folgende Befehl kann verwendet werden, um ein Backup-Image zu validieren:
[root@mysql80~]#mysqlbackup--backup-image=/backupdir/my.mbi validateMySQLEnterpriseBackupVer8.0.36-commercialforLinuxonx86_64(MySQLEnterprise-Commercial)Copyright(c)2003,2024,Oracleand/oritsaffiliates.OracleisaregisteredtrademarkofOracleCorporationand/oritsaffiliates.Othernamesmaybetrademarksoftheirrespectiveowners.Startingwithfollowingcommandline...mysqlbackup--backup-image=/backupdir/my.mbivalidateIMPORTANT:Pleasecheckthatmysqlbackupruncompletessuccessfully.Attheendofasuccessful'validate'runmysqlbackupprints"mysqlbackup completed OK!".24021611:49:26MAININFO:BackupImageMEBversionstring:8.0.3624021611:49:26MAININFO:MySQLserverversionis'8.0.36'24021611:49:26MAININFO:Thebackupimagehasnokeyring.24021611:49:26MAININFO:Creating14bufferseachofsize16777216.24021611:49:26MAININFO:Validateoperationstartswithfollowingthreads1read-threads6process-threads24021611:49:26MAININFO:Validatingimage.../backupdir/my.mbi24021611:49:26PCR6INFO:Validate:[Dir]:meta24021611:49:26PCR5INFO:Validate:[Dir]:datadir/appdb24021611:49:26PCR5INFO:Validate:[Dir]:datadir/datafile24021611:49:26PCR6INFO:Validate:[Dir]:datadir/mydatabase24021611:49:26PCR4INFO:Validate:[Dir]:datadir/mysql24021611:49:26PCR3INFO:Validate:[Dir]:datadir/mytestdb
Nach Abschluss der Validierung erhältst du den Abschlussstatus der Sicherung, der im Protokoll angezeigt wird:
240216 11:49:26 MAIN INFO: datadir/sakila/ fts_0000000000000442_being_deleted.ibd validated. 240216 11:49:26 MAIN INFO: Validate operation completed successfully. 240216 11:49:26 MAIN INFO: Backup Image validation successful. 240216 11:49:26 MAIN INFO: Source Image Path = /backupdir/my.mbi mysqlbackup completed OK! [root@mysql80 ~]#
Schauen wir uns das genauer an:
mysqlbackup-
Validiert das Sicherungsimage
--backup-image-
Gibt den Pfad zum Backup-Image an
--validate-
Gibt die Validierungsoperation an
Wenn die Validierung erfolgreich war, wird die folgende Meldung angezeigt:
mysqlbackup completed OK!
Es ist außerdem wichtig, die Sicherungsprotokolle zu überprüfen, um sicherzustellen, dass während des Sicherungsvorgangs keine Fehler aufgetreten sind. Zum Beispiel:
[root@mysql80meta]#catMEB_2024-02-16.11-42-48_backup-to-image.log|grep"error"[root@mysql80meta]#
Mit diesen Befehlen werden die Backup-bezogenen Einträge in den Backup-Logdateien angezeigt.
Je nach Situation, wie z.B. einem Absturz, menschlichem Versagen und Datenverlust oder einer Disaster Recovery, kann die Wiederherstellung einer Datenbank eine entscheidende Aktivität sein. Bevor du ein Backup wiederherstellst, musst du die MySQL-Instanz herunterfahren, um Probleme mit der Dateninkonsistenz zu vermeiden. Mit dem folgenden Befehl kannst du den MySQL-Server anhalten:
[root@mysql80meta]#systemctlstopmysqld[root@mysql80meta]#
Nachdem du den MySQL-Server heruntergefahren hast, lösche alle Dateien, die sich im Datenverzeichnis befinden. Löschen Sie alle Dateien, die sich unter dem Verzeichnis befinden, das durch die Wiederherstellungsoptionen --innodb_data_home_dir, --innodb_log_group_home_dir und--innodb_undo_directory angegebenen Verzeichnisse befinden, auch wenn es sich um andere Verzeichnisse als dasDatenverzeichnis handelt.
Bevor du den Befehl rm -rf * ausführst, vergewissere dich, dass du dich im richtigen aktuellen Verzeichnis befindest und bestätige, dass es das Datenverzeichnis ist:
[root@mysql80mysql]#pwd/var/lib/mysql[root@mysql80mysql]#rm-rf*[root@mysql80mysql]#
Sobald du alle notwendigen Dateien gelöscht hast, kannst du mit der Optioncopy-back-and-apply-log und dem Befehl mysqlbackup das Backup wiederherstellen. Mit dieser Option werden alle inkrementellen Änderungen aus dem Backup auf den Zielserver übertragen. Hier ist ein Beispielbefehl für deine Referenz:
[root@mysql80backup-tmp]#mysqlbackup--datadir=/var/lib/mysql--backup-image=/backupdir/my.mbi --backup-dir=/backupdir/backup-tmp1copy-back-and-apply-logMySQLEnterpriseBackupVer8.0.36-commercialforLinuxonx86_64(MySQLEnterprise-Commercial)Copyright(c)2003,2024,Oracleand/oritsaffiliates.OracleisaregisteredtrademarkofOracleCorporationand/oritsaffiliates.Othernamesmaybetrademarksoftheirrespectiveowners.Startingwithfollowingcommandline...mysqlbackup--datadir=/var/lib/mysql--backup-image=/backupdir/my.mbi--backup-dir=/backupdir/backup-tmp1copy-back-and-apply-log...24021612:10:24PCR1INFO:LastMySQLbinlogfileposition04131,filenamebinlog.00001224021612:10:24PCR1INFO:Thefirstdatafileis'/var/lib/mysql/datafile/ibdata1'andthenewcreatedlogfilesareat'/var/lib/mysql'24021612:10:24MAININFO:Apply-logoperationcompletedsuccessfully.24021612:10:24MAININFO:FullBackuphasbeenrestoredsuccessfully.mysqlbackupcompletedOK![root@mysql80backup-tmp]#
Der Eigentümer der wiederhergestellten Dateien ist derzeit der Benutzer root:
[root@mysql80mysql]#cd/var/lib/mysql[root@mysql80mysql]#[root@mysql80mysql]#ls-ltrtotal80104-rw-r-----. 1root root56 Feb 16 12:10 backup-auto.cnf-rw-r-----. 1root root14 Feb 16 12:10 backup-mysqld-auto.cnfdrwxr-x---. 2root root28 Feb 16 12:10 sysdrwxr-x---. 2root root91 Feb 16 12:10 worlddrwxr-x---. 2root root4096 Feb 16 12:10 sakiladrwxr-x---. 2root root44 Feb 16 12:10 mydatabase-rw-r-----. 1root root114688 Feb 16 12:10 my_tablespace.ibddrwxr-x---. 2root root164 Feb 16 12:10 appdbdrwxr-x---. 2root root72 Feb 16 12:10 datafile-rw-r-----. 1root root180 Feb 16 12:10 binlog.000011-rw-r-----. 1root root1102 Feb 16 12:10 binlog.000010drwxr-x---. 2root root140 Feb 16 12:10 mytestdbdrwxr-x---. 2root root170 Feb 16 12:10 mysqldrwxr-x---. 2root root8192 Feb 16 12:10 performance_schema-rw-r-----. 1root root4131 Feb 16 12:10 binlog.000012-rw-r-----. 1root root192 Feb 16 12:10 binlog.index-rw-r-----. 1root root660 Feb 16 12:10 server-my.cnf-rw-r-----. 1root root19983 Feb 16 12:10 server-all.cnf-rw-r-----. 1root root16777216 Feb 16 12:10 undo_002-rw-r-----. 1root root16777216 Feb 16 12:10 undo_001-rw-r-----. 1root root16777216 Feb 16 12:10 my_undo_tablespace.ibu-rw-r-----. 1root root27262976 Feb 16 12:10 mysql.ibddrwxr-x---. 2root root23 Feb 16 12:10 'innodb_redo'-rw-r--r--. 1root root723 Feb 16 12:10 backup_variables.txt[root@mysql80mysql]
Nachdem du das Backup wiederhergestellt hast, ändere die Eigentumsrechte an den wiederhergestellten Dateien auf den Benutzer mysql. Du kannst den folgenden Befehl verwenden, um die Eigentümerschaft zu ändern:
[root@mysql80mysql]#chown-Rmysql.mysql/var/lib/mysql[root@mysql80mysql]#[root@mysql80mysql]#ls-ltrtotal80104-rw-r-----. 1mysql mysql56 Feb 16 12:10 backup-auto.cnf-rw-r-----. 1mysql mysql14 Feb 16 12:10 backup-mysqld-auto.cnfdrwxr-x---. 2mysql mysql28 Feb 16 12:10 sysdrwxr-x---. 2mysql mysql91 Feb 16 12:10 worlddrwxr-x---. 2mysql mysql4096 Feb 16 12:10 sakiladrwxr-x---. 2mysql mysql44 Feb 16 12:10 mydatabase-rw-r-----. 1mysql mysql114688 Feb 16 12:10 my_tablespace.ibddrwxr-x---. 2mysql mysql164 Feb 16 12:10 appdbdrwxr-x---. 2mysql mysql72 Feb 16 12:10 datafile-rw-r-----. 1mysql mysql180 Feb 16 12:10 binlog.000011-rw-r-----. 1mysql mysql1102 Feb 16 12:10 binlog.000010drwxr-x---. 2mysql mysql140 Feb 16 12:10 mytestdbdrwxr-x---. 2mysql mysql170 Feb 16 12:10 mysqldrwxr-x---. 2mysql mysql8192 Feb 16 12:10 performance_schema-rw-r-----. 1mysql mysql4131 Feb 16 12:10 binlog.000012-rw-r-----. 1mysql mysql192 Feb 16 12:10 binlog.index-rw-r-----. 1mysql mysql660 Feb 16 12:10 server-my.cnf-rw-r-----. 1mysql mysql19983 Feb 16 12:10 server-all.cnf-rw-r-----. 1mysql mysql16777216 Feb 16 12:10 undo_002-rw-r-----. 1mysql mysql16777216 Feb 16 12:10 undo_001-rw-r-----. 1mysql mysql16777216 Feb 16 12:10 my_undo_tablespace.ibu-rw-r-----. 1mysql mysql27262976 Feb 16 12:10 mysql.ibddrwxr-x---. 2mysql mysql23 Feb 16 12:10 'innodb_redo'-rw-r--r--. 1mysql mysql723 Feb 16 12:10 backup_variables.txt[root@mysql80mysql]
Sobald du die Besitzverhältnisse geändert hast, starte den MySQL-Server mit dem folgenden Befehl:
[root@mysql80mysql]#systemctlstartmysqld[root@mysql80mysql]#
Wenn du ein Backup auf einer Replikationsinstanz wiederherstellst, brauchst du den Namen der binären Logdatei und die Position, ab der die Replikation beginnen soll. Diese Angaben findest du in der Datei backup_variables.txt, die sich in einem Meta-Verzeichnis im Backup-Verzeichnis befindet. Öffne die Datei und rufe die letzte binäre Log-Position sowie die entsprechende Logfile-Nummer ab, die beide in der Datei gespeichert sind. Diese Informationen werden benötigt, um den Replikat-Server so zu konfigurieren, dass die Replikation an der richtigen Position im Binärprotokoll beginnt:
[root@mysql80meta]#pwd/backupdir/backup-tmp/meta[root@mysql80meta]#catbackup_variables.txt|grepbinlog_positionbinlog_position=binlog.000012:4131[root@mysql80meta]#
Percona XtraBackup
Percona XtraBackup ist ein Open-Source-Tool für die Sicherung und Wiederherstellung von MySQL-Datenbanken. Bevor du Sicherungen mit Percona XtraBackup durchführst, müssen bestimmte Voraussetzungen erfüllt sein:
-
Percona XtraBackup muss auf dem Server installiert sein.
-
Die MySQL-Instanz, die gesichert werden soll, muss laufen und zugänglich sein.
-
Es muss genügend Speicherplatz zur Verfügung stehen, um das Backup in einer lokalen Freigabe oder auf einem Remote-Server zu speichern.
Sichern von einem Replikationsserver
Es wird empfohlen, ein vollständiges Backup von einem Replikat-Server mit Percona XtraBackup durchzuführen, um die Auswirkungen auf den Primärserver zu reduzieren. Das Starten eines Backups auf dem Primärserver kann die Leistung beeinträchtigen, was sich auf die Anwendungen auswirken kann, die auf ihn angewiesen sind. Indem du das Backup von einem Replikat-Server erstellst, kannst du die Auswirkungen auf den Primärserver minimieren, so dass dieser die Anwendungen weiterhin ohne Unterbrechung bedienen kann.
Eine Vollsicherung, bei der die gesamte Datenbank gesichert wird, ist die umfassendste Art der Sicherung. Die Sicherung umfasst alle Daten, Indizes, Tabellen, Ansichten, Trigger und Stored Procedures. Hier ist ein Beispiel:
[root@mysql80~]#xtrabackup--backup --target-dir=/root/backupdir -u root -p2024-02-20T07:27:13.279554-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-20T07:27:13.279897-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --backup=1 --target-dir=/root/backupdir--user=root --passwordEnterpassword:xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)24022007:27:14version_checkConnectingtoMySQLserverwithDSN'dbi:mysql:;mysql_read_default_group=xtrabackup'as'root'(usingpassword:YES).24022007:27:14version_checkConnectedtoMySQLserver24022007:27:14version_checkExecutingaversioncheckagainsttheserver...#Asoftwareupdateisavailable:24022007:27:15version_checkDone.2024-02-20T07:27:15.257381-00:000[Note][MY-011825][Xtrabackup]ConnectingtoMySQLserverhost:localhost,user:root,password:set,port:notset,socket:notset2024-02-20T07:27:15.269103-00:000[Note][MY-011825][Xtrabackup]Usingserverversion8.0.36..2024-02-20T07:27:19.627144-00:000[Note][MY-011825][Xtrabackup]Writing/root/backupdir/backup-my.cnf2024-02-20T07:27:19.627324-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/root/backupdir/backup-my.cnf2024-02-20T07:27:19.736769-00:000[Note][MY-011825][Xtrabackup]Writing/root/backupdir/xtrabackup_info2024-02-20T07:27:19.736961-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/root/backupdir/xtrabackup_info2024-02-20T07:27:19.768177-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(20366453)to(20366463)wascopied.2024-02-20T07:27:19.998055-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql80~]#
In den Percona-Dokumenten findest du eine vollständige Liste der Variablenoptionen, die mit dem Tool verfügbar sind.
Hier sind die Details zu den beiden Optionen, die in dem Befehl verwendet werden. Um ein Backup zu starten, führe XtraBackup mit der Option --backup aus. Die Option --target-dir=DIRECTORY gibt das Zielverzeichnis für die Sicherung an. Wenn das angegebene Verzeichnis nicht existiert, wird es von XtraBackup erstellt. Wenn das Verzeichnis existiert und leer ist, wird die Sicherung erfolgreich durchgeführt. Wenn das Verzeichnis jedoch bereits Dateien enthält, überschreibt XtraBackup diese nicht, was zu einem Fehlschlag mit dem Betriebssystemfehler 17 (Datei existiert) führt.
Hinweis
Die Option --slave-info ist besonders nützlich, wenn du ein Backup eines Replikations-Slave-Servers erstellst. Sie zeigt nicht nur den Namen und die Binärprotokollposition des Masterservers an, sondern speichert diese Informationen auch in der Datei xtrabackup_slave_info als CHANGE MASTERBefehl. So kannst du bequem einen neuen Slave-Server für denselben Master einrichten, indem du einen Slave-Server auf dem Backup startest und den BefehlCHANGE MASTER unter Verwendung der in der Dateixtrabackup_slave_info gespeicherten binären Protokollposition ausführst.
Wiederherstellung einer Datenbank
In diesem Abschnitt wird erklärt, wie du ein mit Percona XtraBackup erstelltes Backup wiederherstellen kannst. Bevor du das Backup wiederherstellen kannst, musst du die Sicherungsdateien jedoch mit dem Befehl xtrabackup --prepare vorbereiten. In diesem Schritt werden die anstehenden Änderungen auf die Sicherungsdaten angewendet, damit sie in einem konsistenten Zustand sind:
[root@mysql80~]#xtrabackup--prepare --target-dir=/root/backupdir2024-02-20T07:29:48.539204-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_checksum_algorithm=crc32 --innodb_log_checksums=1--innodb_data_file_path=ibdata1:12M:autoextend --innodb_log_file_size=50331648--innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2--server-id=0 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0--innodb_undo_log_encrypt=02024-02-20T07:29:48.539575-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--prepare=1 --target-dir=/root/backupdirxtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-20T07:29:48.539839-00:000[Note][MY-011825][Xtrabackup]cdto/root/backupdir/2024-02-20T07:29:48.543518-00:000[Note][MY-011825][Xtrabackup]Thistargetseemstobenotpreparedyet.2024-02-20T07:29:48.562638-00:000[Note][MY-011825][Xtrabackup]xtrabackup_logfiledetected:size=8388608,start_lsn=(20366453)..2024-02-20T07:29:49.169641-00:000[Note][MY-011825][Xtrabackup]Completedloadingof2tablespacesintocachein0.00413599seconds2024-02-20T07:29:49.221375-00:000[Note][MY-011825][Xtrabackup]Timetakentobuilddictionary:0.0515769seconds2024-02-20T07:29:49.239865-00:000[Note][MY-011825][Xtrabackup]startingshutdownwithinnodb_fast_shutdown=12024-02-20T07:29:49.240024-00:000[Note][MY-012330][InnoDB]FTSoptimizethreadexiting.2024-02-20T07:29:50.232093-00:000[Note][MY-013072][InnoDB]Startingshutdown...2024-02-20T07:29:50.240493-00:000[Note][MY-013084][InnoDB]Logbackgroundthreadsarebeingclosed...2024-02-20T07:29:50.260550-00:000[Note][MY-012980][InnoDB]Shutdowncompleted;logsequencenumber203668702024-02-20T07:29:50.266082-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql80~]#
Beende den MySQL-Server auf dem Rechner, auf dem du das Backup wiederherstellen willst:
[root@mysql80~]#sudosystemctlstopmysqld[root@mysql80~]#
Kopiere die Sicherungsdateien von ihrem ursprünglichen Speicherort zu dem Zielort, an dem du die Wiederherstellung durchführen willst. Dafür kannst du ein Tool wie rsync oder scp verwenden.
Kopiere die MySQL-Konfigurationsdateien vom Speicherort der Sicherung in das MySQL-Konfigurationsverzeichnis auf dem Rechner, auf dem du die Sicherung wiederherstellen willst. Der Speicherort des Konfigurationsverzeichnisses kann je nach Betriebssystem variieren. Wenn die Sicherung nicht in das Datenverzeichnis kopiert wurde, kannst du den Befehl xtrabackup--copy-back Befehl verwenden, um die Dateien aus dem Backup-Verzeichnis in das MySQL-Datenverzeichnis zu kopieren:
[root@mysql80~]#sudoxtrabackup--copy-back --target-dir=/root/backupdir2024-02-20T07:34:03.208252-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-20T07:34:03.208429-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --copy-back=1 --target-dir=/root/backupdirxtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-20T07:34:03.208499-00:000[Note][MY-011825][Xtrabackup]cdto/root/backupdir/2024-02-20T07:34:03.212994-00:000[Note][MY-011825][Xtrabackup]Copyingundo_001to/var/lib/mysql/undo_0012024-02-20T07:34:03.372784-00:000[Note][MY-011825][Xtrabackup]Done:Copyingundo_001to/var/lib/mysql/undo_0012024-02-20T07:34:03.379912-00:000[Note][MY-011825][Xtrabackup]Copyingundo_002to/var/lib/mysql/undo_0022024-02-20T07:34:03.481821-00:000[Note][MY-011825][Xtrabackup]Done:Copyingundo_002to/var/lib/mysql/undo_0022024-02-20T07:34:03.488697-00:000[Note][MY-011825][Xtrabackup]Copyingibdata1to/var/lib/mysql/ibdata12024-02-20T07:34:03.557571-00:000[Note][MY-011825][Xtrabackup]Done:Copyingibdata1to/var/lib/mysql/ibdata1...2024-02-20T07:34:04.081817-00:001[Note][MY-011825][Xtrabackup]Copying./ib_buffer_poolto/var/lib/mysql/ib_buffer_pool2024-02-20T07:34:04.082713-00:001[Note][MY-011825][Xtrabackup]Done:Copying./ib_buffer_poolto/var/lib/mysql/ib_buffer_pool2024-02-20T07:34:04.084413-00:001[Note][MY-011825][Xtrabackup]Copying./xtrabackup_infoto/var/lib/mysql/xtrabackup_info2024-02-20T07:34:04.084548-00:001[Note][MY-011825][Xtrabackup]Done:Copying./xtrabackup_infoto/var/lib/mysql/xtrabackup_info2024-02-20T07:34:04.086055-00:001[Note][MY-011825][Xtrabackup]Creatingdirectory./#innodb_redo2024-02-20T07:34:04.086133-00:001[Note][MY-011825][Xtrabackup]Done:creatingdirectory./#innodb_redo2024-02-20T07:34:04.086241-00:001[Note][MY-011825][Xtrabackup]Copying./ibtmp1to/var/lib/mysql/ibtmp12024-02-20T07:34:04.131401-00:001[Note][MY-011825][Xtrabackup]Done:Copying./ibtmp1to/var/lib/mysql/ibtmp12024-02-20T07:34:04.177825-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql80~]#
Nachdem du die Dateien kopiert hast, musst du den Eigentümer und die Rechte für das Datenverzeichnis auf den Benutzer mysql setzen:
[root@mysql80~]#sudochown-Rmysql:mysql/var/lib/mysql[root@mysql80~]#
Starte den MySQL-Server mit dem folgenden Befehl:
[root@mysql80~]#sudosystemctlstartmysqld[root@mysql80~]#
Nachdem du MySQL gestartet hast, musst du das Protokoll überprüfen und bestätigen, dass die MySQL-Instanz bereit für die Verbindung ist. Wenn du tail das mysqld Fehlerprotokoll überprüfst, solltest du ein ähnliches Ergebnis erhalten:
[root@mysql80~]#tail-2/var/log/mysqld.log2024-02-20T07:37:48.624988Z0[System][MY-011323][Server]XPluginreadyforconnections.Bind-address:'::'port:33060,socket:/var/run/mysqld/mysqlx.sock2024-02-20T07:37:48.625234Z0[System][MY-010931][Server]/usr/sbin/mysqld:readyforconnections.Version:'8.0.36'socket:'/var/lib/mysql/mysql.sock'port:3306MySQLCommunityServer-GPL.[root@mysql80~]#
Inkrementelle Backups verwenden
Percona XtraBackup unterstützt inkrementelle Backups, so dass nur die Daten kopiert werden, die sich seit dem letzten Backup geändert haben. Du kannst mehrere inkrementelle Backups durchführen. So kannst du einen Backup-Zeitplan erstellen, z. B. einmal pro Woche ein vollständiges Backup und täglich inkrementelle Backups oder täglich ein vollständiges Backup und stündlich inkrementelle Backups.
Der inkrementelle Sicherungsprozess nutzt die LSN, die mit jeder InnoDB-Seite verknüpft ist. Die LSN dient als Systemversionsnummer für die gesamte Datenbank und zeigt an, wann eine Seite zuletzt geändert wurde. Bei einer inkrementellen Sicherung werden nur Seiten kopiert, deren LSN neuer ist als die LSN der vorherigen inkrementellen oder vollständigen Sicherung. Ein Algorithmus identifiziert die Seiten, die dieses Kriterium erfüllen, indem er die Datenseiten liest und ihre jeweiligen LSN-Werte überprüft.
Um eine inkrementelle Sicherung mit Percona XtraBackup zu erstellen, beginnst du mit einer regulären Vollsicherung. Nach der Vollsicherung schreibt das Dienstprogramm xtrabackupeine Datei namens xtrabackup_checkpoints in das Zielverzeichnis der Sicherung. Diese Datei enthält eine Zeilemit der Bezeichnung to_lsn, die die LSN der Datenbank am Ende des Sicherungsvorgangs darstellt. Du kannst eine vollständige Sicherung durchführen, indem du den folgenden Befehl ausführst:
[root@mysql8~]#mkdir-p/data/backups/base[root@mysql8~]#xtrabackup--backup --target-dir=/data/backups/base2024-02-23T11:50:13.697883-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-23T11:50:13.698792-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --backup=1 --target-dir=/data/backups/basextrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)Can'tlocateEnglish.pmin@INC(youmayneedtoinstalltheEnglishmodule)(@INCcontains:/usr/local/lib64/perl5/5.32/usr/local/share/perl5/5.32/usr/lib64/perl5/vendor_perl/usr/share/perl5/vendor_perl/usr/lib64/perl5/usr/share/perl5)at-line3.BEGINfailed--compilation aborted at - line 3.2024-02-23T11:50:13.728094-00:000[Note][MY-011825][Xtrabackup]ConnectingtoMySQLserverhost:localhost,user:root,password:set,port:notset,socket:notset2024-02-23T11:50:14.135079-00:000[Note][MY-011825][Xtrabackup]Usingserverversion8.0.362024-02-23T11:50:14.149822-00:000[Note][MY-011825][Xtrabackup]ExecutingLOCKINSTANCEFORBACKUP...2024-02-23T11:50:14.151389-00:000[Note][MY-011825][Xtrabackup]usesposix_fadvise().2024-02-23T11:50:14.151443-00:000[Note][MY-011825][Xtrabackup]cdto/var/lib/mysql2024-02-23T11:50:14.151460-00:000[Note][MY-011825][Xtrabackup]openfileslimitrequested0,setto10242024-02-23T11:50:14.174389-00:000[Note][MY-011825][Xtrabackup]usingthefollowingInnoDBconfiguration:2024-02-23T11:50:14.174418-00:000[Note][MY-011825][Xtrabackup]innodb_data_home_dir=.2024-02-23T11:50:14.174429-00:000[Note][MY-011825][Xtrabackup]innodb_data_file_path=ibdata1:12M:autoextend2024-02-23T11:50:14.174470-00:000[Note][MY-011825][Xtrabackup]innodb_log_group_home_dir=./2024-02-23T11:50:14.174482-00:000[Note][MY-011825][Xtrabackup]innodb_log_files_in_group=2....2024-02-23T11:50:32.554338-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/base/backup-my.cnf2024-02-23T11:50:33.071966-00:000[Note][MY-011825][Xtrabackup]Writing/data/backups/base/xtrabackup_info2024-02-23T11:50:33.072211-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/base/xtrabackup_info2024-02-23T11:50:33.188617-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(20289655)to(20289665)wascopied.2024-02-23T11:50:33.405903-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8~]#
Nach Abschluss der Vollsicherung kannst du die Dateixtrabackup_checkpoints einsehen, um den LSN-Wert zu überprüfen. Je nach LSN-Nummer enthält die Datei ähnliche Informationen wie die folgenden:
[root@mysql8~]#cat/data/backups/base/xtrabackup_checkpointsbackup_type=full-backupedfrom_lsn=0to_lsn=20289655last_lsn=20289655flushed_lsn=20289655redo_memory=0redo_frames=0[root@mysql8~]#
Diese Ausgabe bestätigt, dass die Vollsicherung erfolgreich war und zeigt den Wertto_lsn an, der als Referenzpunkt für die nächste inkrementelle Sicherung verwendet wird.
Nachdem du ein vollständiges Backup erstellt hast, kannst du mit dem Befehl xtrabackup ein inkrementelles Backup erstellen. Der folgende Befehl kann verwendet werden, um ein inkrementelles Backup zu erstellen:
[root@mysql8~]#xtrabackup--backup --target-dir=/data/backups/inc1 \--incremental-basedir=/data/backups/base -u root -p2024-02-23T12:07:38.147005-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-23T12:07:38.147368-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --backup=1 --target-dir=/data/backups/inc1--incremental-basedir=/data/backups/base --user=root --passwordEnterpassword:xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)Can't locate English.pm in @INC (you may need to install the English module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/ lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/ share/perl5) at - line 3. BEGIN failed--compilation aborted at - line 3. 2024-02-23T12:07:39.895793-00:00 0 [Note] [MY-011825] [Xtrabackup] Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set 2024-02-23T12:07:39.918181-00:00 0 [Note] [MY-011825] [Xtrabackup] Using server version 8.0.36 2024-02-23T12:07:39.935737-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = ./ 2024-02-23T12:07:52.016205-00:00 0 [Note] [MY-011825] [Xtrabackup] MySQL binlog position: filename 'binlog.000006', position '157'2024-02-23T12:07:52.016406-00:000[Note][MY-011825][Xtrabackup]Writing/data/backups/inc1/backup-my.cnf2024-02-23T12:07:52.016580-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/inc1/backup-my.cnf2024-02-23T12:07:52.185241-00:000[Note][MY-011825][Xtrabackup]Writing/data/backups/inc1/xtrabackup_info2024-02-23T12:07:52.185445-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/inc1/xtrabackup_info2024-02-23T12:07:53.188689-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(20784993)to(20784993)wascopied.2024-02-23T12:07:53.414360-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8~]#
Dieser Befehl erstellt eine inkrementelle Sicherung im Verzeichnis /data/backups/inc1/, die auf der vorherigen Vollsicherung im Verzeichnis/data/backups/base/ basiert. Die von diesem Befehl erzeugten Deltadateien stellen die Änderungen dar, die an der Datenbank seit dem LSN-Wert der vorherigen Sicherung vorgenommen wurden. Im Verzeichnis der inkrementellen Sicherung findest du zum Beispiel Dateien wie ibdata1.delta undtest/table1.ibd.delta.
Nach Abschluss der inkrementellen Sicherung kannst du die Dateixtrabackup_checkpoints im Verzeichnis /data/backups/inc1/ überprüfen. Diese Datei sollte sowohl den neuen LSN-Wert als auch den incremental-basedirWert enthalten, der als Referenzpunkt für den Backup-Prozess verwendet wurde. Der Inhalt der Datei xtrabackup_checkpoints kann wie folgt aussehen:
[root@mysql8~]#cat/data/backups/inc1/xtrabackup_checkpointsbackup_type=incrementalfrom_lsn=20289655to_lsn=20784993last_lsn=20784993flushed_lsn=20784993redo_memory=0redo_frames=0[root@mysql8~]#
Der Wert from_lsn in der Datei xtrabackup_checkpoints stellt die Start-LSN der inkrementellen Sicherung dar und sollte mit dem Wertto_lsn der Checkpoint-Datei der vorherigen oder der Basissicherung übereinstimmen.
Nachdem du die erste inkrementelle Sicherung erstellt hast, kannst du sie als Grundlage für die Erstellung einer weiteren inkrementellen Sicherung verwenden. Mit dem folgenden Befehl kannst du eine inkrementelle Sicherung auf Basis der vorherigen inkrementellen Sicherung erstellen:
[root@mysql8~]#xtrabackup--backup --target-dir=/data/backups/inc2 \--incremental-basedir=/data/backups/inc12024-02-23T13:10:43.005350-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-23T13:10:43.008358-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --backup=1 --target-dir=/data/backups/inc2--incremental-basedir=/data/backups/inc1xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)Can't locate English.pm in @INC (you may need to install the English module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/ lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/ share/perl5) at - line 3. BEGIN failed--compilation aborted at - line 3. 2024-02-23T13:10:43.044764-00:00 0 [Note] [MY-011825] [Xtrabackup] Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set 2024-02-23T13:10:43.053579-00:00 0 [Note] [MY-011825] [Xtrabackup] Using server version 8.0.36 2024-02-23T13:10:43.056222-00:00 0 [Note] [MY-011825] [Xtrabackup] Executing LOCK INSTANCE FOR BACKUP ... 2024-02-23T13:10:43.057492-00:00 0 [Note] [MY-011825] [Xtrabackup] incremental backup from 20784993 is enabled. 2024-02-23T13:10:43.057721-00:00 0 [Note] [MY-011825] [Xtrabackup] uses posix_fadvise(). 2024-02-23T13:10:43.057745-00:00 0 [Note] [MY-011825] [Xtrabackup] cd to /var/ lib/mysql 2024-02-23T13:10:43.057757-00:00 0 [Note] [MY-011825] [Xtrabackup] open files limit requested 0, set to 1024 2024-02-23T13:10:43.060579-00:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration: 2024-02-23T13:10:43.060604-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = . 2024-02-23T13:10:43.060613-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:12M:autoextend 2024-02-23T13:10:43.060650-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = ./ 2024-02-23T13:10:43.060662-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 2 2024-02-23T13:10:43.060672-00:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 50331648 .... 2024-02-23T13:10:50.751443-00:00 0 [Note] [MY-011825] [Xtrabackup] MySQL binlog position: filename 'binlog.000011', position '157'2024-02-23T13:10:50.814250-00:000[Note][MY-011825][Xtrabackup]Writing/data/backups/inc2/backup-my.cnf2024-02-23T13:10:50.814471-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/inc2/backup-my.cnf2024-02-23T13:10:51.014542-00:000[Note][MY-011825][Xtrabackup]Writing/data/backups/inc2/xtrabackup_info2024-02-23T13:10:51.014890-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/data/backups/inc2/xtrabackup_info2024-02-23T13:10:51.018154-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(21291941)to(21291941)wascopied.2024-02-23T13:10:51.140104-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8~]#
Dieser Befehl erstellt eine neue inkrementelle Sicherung im Verzeichnis /data/backups/inc2/, die auf der vorherigen inkrementellen Sicherung in/data/backups/inc1/ basiert. Die Datei xtrabackup_checkpoints in diesem Verzeichnis sollte den neuen LSN-Wert anzeigen, der den Endpunkt der neuen inkrementellen Sicherung darstellt.
Du kannst auf diese Weise mehrere inkrementelle Backups erstellen, wobei jedes neue inkrementelle Backup auf dem vorherigen Backup basiert. Jede inkrementelle Sicherung enthält nur die Änderungen, die seit der vorherigen Sicherung vorgenommen wurden, was dazu beiträgt, den Zeit- und Speicherbedarf für Sicherungs- und Wiederherstellungsvorgänge zu reduzieren:
[root@mysql8~]#cat/data/backups/inc2/xtrabackup_checkpointsbackup_type=incrementalfrom_lsn=20784993to_lsn=21291941last_lsn=21291941flushed_lsn=21291941redo_memory=0redo_frames=0[root@mysql8~]#
Du hast jetzt eine Vollsicherung und zwei inkrementelle Sicherungen erstellt, die alle im Sicherungsverzeichnis gespeichert werden. Jede Sicherung wird in einem eigenen Verzeichnis in diesem Backup-Verzeichnis gespeichert. Wenn du dir den Inhalt des Backup-Verzeichnisses mit dem Befehlls -ltr Befehl auflistest, findest du die folgenden:
[root@mysql8backups]#ls-ltrtotal12drwxr-xr-x.5rootroot4096Feb2311:50basedrwxr-x---. 6 root root 4096 Feb 23 12:07 inc1drwxr-x---. 6 root root 4096 Feb 23 13:10 inc2[root@mysql8backups]#
Vorbereiten inkrementeller Backups
Der --prepare Schritt für inkrementelle Backups unterscheidet sich von dem für vollständige Backups. Bei Voll-Backups führt der Schritt --prepare zwei Arten von Operationen durch, um die Datenbank konsistent zu machen: Er gleicht festgeschriebene Transaktionen aus der Logdatei mit den Datendateien ab und rollt nicht festgeschriebene Transaktionen zurück. Bei der Vorbereitung eines inkrementellen Backups musst du jedoch das Rollback von unbestätigten Transaktionen auslassen. Der Grund dafür ist, dass Transaktionen, die zum Zeitpunkt des Backups noch nicht übertragen wurden, möglicherweise noch in Bearbeitung sind und bei der nächsten inkrementellen Sicherung übertragen werden.
Um die Rollback-Phase während des --prepare Schritts für inkrementelle Backups zu verhindern, verwendest du die Option --apply-log-only. Diese Option wendet nur die Logfiles auf das Backup an, um die Seiten zu aktualisieren, und führt kein Rollback der Transaktionen durch. Nach der Anwendung der Logdateien kann das Backup zum Zeitpunkt der Erstellung des Backups wiederhergestellt werden:
[root@mysql8backups]#xtrabackup--prepare --apply-log-only \--target-dir=/data/backups/base2024-02-23T13:28:08.266142-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_checksum_algorithm=crc32 --innodb_log_checksums=1--innodb_data_file_path=ibdata1:12M:autoextend --innodb_log_file_size=50331648--innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2--server-id=0 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0--innodb_undo_log_encrypt=02024-02-23T13:28:08.266501-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--prepare=1 --apply-log-only=1 --target-dir=/data/backups/basextrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-23T13:28:08.266735-00:000[Note][MY-011825][Xtrabackup]cdto/data/backups/base/2024-02-23T13:28:08.268271-00:000[Note][MY-011825][Xtrabackup]Thistargetseemstobenotpreparedyet.2024-02-23T13:28:08.290071-00:000[Note][MY-011825][Xtrabackup]inititialize_service_handlessuceeded2024-02-23T13:28:08.290782-00:000[Note][MY-011825][Xtrabackup]usingthefollowingInnoDBconfigurationforrecovery:2024-02-23T13:28:08.290856-00:000[Note][MY-011825][Xtrabackup]innodb_data_home_dir=.2024-02-23T13:28:08.290906-00:000[Note][MY-011825][Xtrabackup]innodb_data_file_path=ibdata1:12M:autoextend
Nach Beendigung dieses Befehls sollte die Ausgabe mit einem Text ähnlich diesem enden:
2024-02-23T13:28:09.840970-00:000[Note][MY-013072][InnoDB]Startingshutdown...2024-02-23T13:28:09.848432-00:000[Note][MY-013084][InnoDB]Logbackgroundthreadsarebeingclosed...2024-02-23T13:28:09.868724-00:000[Note][MY-012980][InnoDB]Shutdowncompleted;logsequencenumber202896652024-02-23T13:28:09.876150-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8backups]#
Um die erste inkrementelle Sicherung auf die Vollsicherung anzuwenden, kannst du den folgenden Befehl ausführen:
[root@mysql8backups]#xtrabackup--prepare --apply-log-only --target-dir=/data/backups/base\--incremental-dir=/data/backups/inc12024-02-23T13:30:43.873233-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_checksum_algorithm=crc32 --innodb_log_checksums=1--innodb_data_file_path=ibdata1:12M:autoextend --innodb_log_file_size=50331648--innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2--server-id=0 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0--innodb_undo_log_encrypt=02024-02-23T13:30:43.874162-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--prepare=1 --apply-log-only=1 --target-dir=/data/backups/base--incremental-dir=/data/backups/inc1xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-23T13:30:43.877184-00:000[Note][MY-011825][Xtrabackup]incrementalbackupfrom20289655isenabled.2024-02-23T13:30:43.877299-00:000[Note][MY-011825][Xtrabackup]cdto/data/backups/base/2024-02-23T13:30:43.878200-00:000[Note][MY-011825][Xtrabackup]Thistargetseemstobealreadypreparedwith--apply-log-only.2024-02-23T13:30:43.888050-00:000[Note][MY-011825][Xtrabackup]xtrabackup_logfiledetected:size=8388608,start_lsn=(20784993)2024-02-23T13:30:43.888535-00:000[Note][MY-011825][Xtrabackup]usingthefollowingInnoDBconfigurationforrecovery:2024-02-23T13:30:43.888643-00:000[Note][MY-011825][Xtrabackup]innodb_data_home_dir=.2024-02-23T13:30:43.888699-00:000[Note][MY-011825][Xtrabackup]innodb_data_file_path=ibdata1:12M:autoextend2024-02-23T13:30:43.888796-00:000[Note][MY-011825][Xtrabackup]innodb_log_group_home_dir=/data/backups/inc1/2024-02-23T13:30:46.424279-00:000[Note][MY-011825][Xtrabackup]Done:Copying/data/backups/inc1/binlog.000006to./binlog.0000062024-02-23T13:30:46.425801-00:000[Note][MY-011825][Xtrabackup]Copying/data/backups/inc1/binlog.indexto./binlog.index2024-02-23T13:30:46.425940-00:000[Note][MY-011825][Xtrabackup]Done:Copying/data/backups/inc1/binlog.indexto./binlog.index2024-02-23T13:30:46.427799-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8backups]#
Dieser Befehl wendet die Deltadateien in /data/backups/inc1 auf die Dateien in /data/backups/base an, wodurch sie auf den Zeitpunkt der inkrementellen Sicherung vorgerollt werden. Anschließend wird das Redo-Log wie üblich auf das Ergebnis angewendet. Die endgültigen Daten befinden sich in /data/backups/base, nicht im inkrementellen Verzeichnis.
Beim Zusammenführen inkrementeller Backups sollte die Option --apply-log-only für alle dazwischenliegenden inkrementellen Backups außer dem letzten verwendet werden. Das liegt daran, dass die Option --apply-log-only die Rollback-Phase überspringt und das Backup nur für die Anwendung des nächsten inkrementellen Backups vorbereitet.
Um das letzte inkrementelle Backup zusammenzuführen, solltest du daher den folgenden Befehl ausführen:
[root@mysql8backups]#xtrabackup--prepare --target-dir=/data/backups/base \--incremental-dir=/data/backups/inc22024-02-23T13:32:54.413264-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_checksum_algorithm=crc32 --innodb_log_checksums=1--innodb_data_file_path=ibdata1:12M:autoextend --innodb_log_file_size=50331648--innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2--server-id=0 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0--innodb_undo_log_encrypt=02024-02-23T13:32:54.414978-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--prepare=1 --target-dir=/data/backups/base--incremental-dir=/data/backups/inc2xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-23T13:32:54.415995-00:000[Note][MY-011825][Xtrabackup]incrementalbackupfrom20784993isenabled.2024-02-23T13:32:54.416111-00:000[Note][MY-011825][Xtrabackup]cdto/data/backups/base/2024-02-23T13:32:54.416290-00:000[Note][MY-011825][Xtrabackup]Thistargetseemstobealreadypreparedwith--apply-log-only.2024-02-23T13:32:54.426669-00:000[Note][MY-011825][Xtrabackup]xtrabackup_logfiledetected:size=8388608,start_lsn=(21291941)2024-02-23T13:32:54.427121-00:000[Note][MY-011825][Xtrabackup]usingthefollowingInnoDBconfigurationforrecovery:2024-02-23T13:32:54.427198-00:000[Note][MY-011825][Xtrabackup]innodb_data_home_dir=.2024-02-23T13:32:54.427266-00:000[Note][MY-011825][Xtrabackup]innodb_data_file_path=ibdata1:12M:autoextend2024-02-23T13:32:54.427333-00:000[Note][MY-011825][Xtrabackup]innodb_log_group_home_dir=/data/backups/inc2/2024-02-23T13:32:57.169249-00:000[Note][MY-011825][Xtrabackup]Done:Copying/data/backups/inc2/binlog.000011to./binlog.0000112024-02-23T13:32:57.170686-00:000[Note][MY-011825][Xtrabackup]Copying/data/backups/inc2/binlog.indexto./binlog.index2024-02-23T13:32:57.170819-00:000[Note][MY-011825][Xtrabackup]Done:Copying/data/backups/inc2/binlog.indexto./binlog.index2024-02-23T13:32:57.173092-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql8backups]#
Da dies die letzte inkrementelle Sicherung ist, kannst du --prepare ohne die--apply-log-only Option ausführen. Das Backup ist dann immer noch konsistent, aber der Server führt die Rollback-Phase durch. Nach der Vorbereitung ist das Backup einsatzbereit.
Logische Backups
Die beliebtesten Werkzeuge für logische Backups sind das MySQL Shell Dump Utility, mydumper und mysqldump. In diesem Abschnitt behandeln wir das MySQL Shell Dump Utility und mysqldump und erklären, wie man eine vollständige Sicherung und Wiederherstellung durchführt.
Wir behandeln mydumper und myloader in "Große Datenbanken zu Azure Database for MySQL migrieren". Unter "Konvertieren von Tabellen von MyISAM nach InnoDB" findest du weitere Informationen zur Migration auf Tabellenebene.
Das Dienstprogramm MySQL Shell Dump
MySQL Shell ist ein fortschrittlicher Befehlszeilen-Client und eine Skripting-Schnittstelle für MySQL. Sie bietet eine Reihe leistungsfähiger Dienstprogramme für die Datenbankverwaltung und -administration, darunter das Dump-Dienstprogramm, das für die Sicherung und Wiederherstellung von Datenbanken verwendet wird.
Das Dump Utility ist ein funktionsreiches Werkzeug, das die MySQL Shell für die Sicherung von MySQL-Datenbanken bereitstellt. Es ermöglicht dir, komplette Instanz-Backups oder Teil-Backups ausgewählter Schemas oder Tabellen durchzuführen. Außerdem kannst du den Sicherungsprozess mit den verschiedenen Optionen des Dienstprogramms individuell anpassen.
Nachdem du dich eingeloggt hast, kannst du mit dem Dump-Dienstprogramm Sicherungen durchführen, wie in diesem Beispiel gezeigt:
[root@mysql80~]#mysqlsh--uri root@localhost:3306MySQLShell8.0.36Copyright(c)2016,2023,Oracleand/oritsaffiliates.OracleisaregisteredtrademarkofOracleCorporationand/oritsServerversion:8.0.36MySQLCommunityServer-GPLNodefaultschemaselected;type\use<schema>tosetone.MySQLlocalhost:3306sslJS>
Bevor du das eigentliche Backup durchführst, solltest du einen Trockenlauf durchführen, um den Backup-Prozess zu überprüfen. Der folgende Befehl, util.dumpInstance, kann für den Trockenlauf verwendet werden:
MySQLlocalhost:3306sslJS>util.dumpInstance("/mysqlsh/backuputildump/",{dryRun:"true"})dryRunenabled,nolockswillbeacquiredandnofileswillbecreated.AcquiringglobalreadlockGlobalreadlockacquiredInitializing-done1outof5schemaswillbedumpedandwithinthem1table,0views.1outof4userswillbedumped.Gatheringinformation-doneAlltransactionshavebeenstartedLockinginstanceforbackupGlobalreadlockhasbeenreleasedWritingglobalDDLfilesWritingusersDDLWritingDDL-doneStartingdatadump0%(0rows/~20rows),0.00rows/s,0.00B/suncompressed,0.00B/scompressedMySQLlocalhost:3306sslJS>
Eine Vollsicherung der Instanz stellt sicher, dass du eine Sicherung der gesamten Datenbankinstanz hast, falls unvorhergesehene Umstände eintreten. Mit dem folgenden Kommando kannst du ein vollständiges Instanz-Backup durchführen:
MySQLlocalhost:3306sslJS>util.dumpInstance("/backuputildump")AcquiringglobalreadlockGlobalreadlockacquiredInitializing-done1outof5schemaswillbedumpedandwithinthem1table,0views.1outof4userswillbedumped.Gatheringinformation-doneAlltransactionshavebeenstartedLockinginstanceforbackupGlobalreadlockhasbeenreleasedWritingglobalDDLfilesWritingusersDDLRunningdatadumpusing4threads.NOTE:Progressinformationusesestimatedvaluesandmaynotbeaccurate.Writingschemametadata-doneWritingDDL-doneWritingtablemetadata-doneStartingdatadump100%(20rows/~20rows),0.00rows/s,0.00B/suncompressed,0.00B/scompressedDumpduration:00:00:00sTotalduration:00:00:00sSchemasdumped:1Tablesdumped:1Uncompresseddatasize:727bytesCompresseddatasize:258bytesCompressionratio:2.8Rowswritten:20Byteswritten:258bytesAverageuncompressedthroughput:727.00B/sAveragecompressedthroughput:258.00B/sMySQLlocalhost:3306sslJS>
Das Backup wird in folgendem Verzeichnis gespeichert:
[root@mysql80~]#ls-ltr/backuputildumptotal44-rw-r-----. 1 root root 240 Feb 20 10:37 @.sql-rw-r-----. 1 root root 240 Feb 20 10:37 @.post.sql-rw-r-----. 1 root root 774 Feb 20 10:37 @.json-rw-r-----. 1 root root 1965 Feb 20 10:37 @.users.sql-rw-r-----. 1 root root 301 Feb 20 10:37 mytestdb.json-rw-r-----. 1 root root 575 Feb 20 10:37 mytestdb.sql-rw-r-----. 1 root root 784 Feb 20 10:37 mytestdb@test_table.sql-rw-r-----. 1 root root 649 Feb 20 10:37 mytestdb@test_table.json-rw-r-----. 1 root root 8 Feb 20 10:37 mytestdb@test_table@@0.tsv.zst.idx-rw-r-----. 1 root root 258 Feb 20 10:37 mytestdb@test_table@@0.tsv.zst-rw-r-----. 1 root root 228 Feb 20 10:37 @.done.json[root@mysql80~]#
Um den Instanz-Dump mit erweiterten Optionen auszuführen, verwende den folgenden Befehl:
MySQLlocalhost:3306sslJS>util.dumpInstance(\"/backuputildump/ mysqlinstance",{threads:8,maxRate:\"100M",consistent:true,chunking:true,bytesPerchunk:\"64M",compression:\"zstd"})AcquiringglobalreadlockGlobalreadlockacquiredInitializing-done1outof5schemaswillbedumpedandwithinthem1table,0views.1outof4userswillbedumped.Gatheringinformation-doneAlltransactionshavebeenstartedLockinginstanceforbackupGlobalreadlockhasbeenreleasedWritingglobalDDLfilesWritingusersDDLRunningdatadumpusing8threads.NOTE:Progressinformationusesestimatedvaluesandmaynotbeaccurate.Writingschemametadata-doneWritingDDL-doneWritingtablemetadata-doneStartingdatadump100%(20rows/~20rows),0.00rows/s,0.00B/suncompressed,0.00B/scompressedDumpduration:00:00:00sTotalduration:00:00:00sSchemasdumped:1Tablesdumped:1Uncompresseddatasize:727bytesCompresseddatasize:258bytesCompressionratio:2.8Rowswritten:20Byteswritten:258bytesAverageuncompressedthroughput:727.00B/sAveragecompressedthroughput:258.00B/sMySQLlocalhost:3306sslJS>
In diesem Befehl kannst du verschiedene Optionen angeben, um den Dump-Prozess zu steuern und zu verbessern. Du kannst z.B. die Anzahl der zu verwendenden Threads, die maximale Geschwindigkeit, mit der das Backup geschrieben werden soll, angeben, ob ein konsistentes Backup durchgeführt werden soll, ob die Backup-Daten in Chunks aufgeteilt werden sollen, wie groß die einzelnen Chunks sein sollen und welcher Kompressionsalgorithmus verwendet werden soll.
Mit dem Schema-Dump-Dienstprogramm kannst du Teil-Backups ausgewählter Schemas durchführen. Du kannst den folgenden Befehl util.dumpSchemas verwenden, um bestimmte Schemas zu sichern:
MySQLlocalhost:3306sslJS>util.dumpSchemas([\"employees"],\"/backupdir/employees",{threads:2})AcquiringglobalreadlockGlobalreadlockacquiredInitializing-done1schemaswillbedumpedandwithinthem2tables,0views.Gatheringinformation-doneAlltransactionshavebeenstartedLockinginstanceforbackupGlobalreadlockhasbeenreleasedWritingglobalDDLfilesRunningdatadumpusing2threads.NOTE:Progressinformationusesestimatedvaluesandmaynotbeaccurate.Writingschemametadata-doneWritingDDL-doneWritingtablemetadata-doneStartingdatadump100%(8rows/~8rows),0.00rows/s,0.00B/suncompressed,0.00B/scompressedDumpduration:00:00:00sTotalduration:00:00:00sSchemasdumped:1Tablesdumped:2Uncompresseddatasize:224bytesCompresseddatasize:182bytesCompressionratio:1.2Rowswritten:8Byteswritten:182bytesAverageuncompressedthroughput:224.00B/sAveragecompressedthroughput:182.00B/sMySQLlocalhost:3306sslJS>
In diesem Befehl kannst du den Speicherort der Sicherung und die Namen der zu sichernden Schemas angeben. Die Sicherung wird im folgenden Verzeichnis gespeichert, das nur für die Datenbank employees gilt:
[root@mysql80~]#ls-ltr/backupdir/employeestotal64-rw-r-----. 1 root root 240 Feb 20 10:51 @.sql-rw-r-----. 1 root root 240 Feb 20 10:51 @.post.sql-rw-r-----. 1 root root 771 Feb 20 10:51 @.json-rw-r-----. 1 root root 362 Feb 20 10:51 employees.json-rw-r-----. 1 root root 716 Feb 20 10:51 employees@salaries.sql-rw-r-----. 1 root root 631 Feb 20 10:51 employees@salaries.json-rw-r-----. 1 root root 798 Feb 20 10:51 employees@employees.sql-rw-r-----. 1 root root 657 Feb 20 10:51 employees@employees.json-rw-r-----. 1 root root 581 Feb 20 10:51 employees.sql-rw-r-----. 1 root root 8 Feb 20 10:51 employees@salaries@0.tsv.zst.idx-rw-r-----. 1 root root 8 Feb 20 10:51 employees@employees@@0.tsv.zst.idx-rw-r-----. 1 root root 52 Feb 20 10:51 employees@salaries@0.tsv.zst-rw-r-----. 1 root root 8 Feb 20 10:51 employees@salaries@@1.tsv.zst.idx-rw-r-----. 1 root root 121 Feb 20 10:51 employees@employees@@0.tsv.zst-rw-r-----. 1 root root 9 Feb 20 10:51 employees@salaries@@1.tsv.zst-rw-r-----. 1 root root 344 Feb 20 10:51 @.done.json[root@mysql80~]#
Mit dem Table Dump Utility kannst du partielle Backups ausgewählter Tabellen durchführen. Verwende den folgenden Befehl, util.dumpTables, um einzelne Tabellen zu sichern:
MySQLlocalhost:3306sslJS>util.dumpTables(\"employees",[\"salaries"],\"/backupdir/employees/salaries",{threads:2})AcquiringglobalreadlockGlobalreadlockacquiredInitializing-done1tablesand0viewswillbedumped.Gatheringinformation-doneAlltransactionshavebeenstartedLockinginstanceforbackupGlobalreadlockhasbeenreleasedWritingglobalDDLfilesRunningdatadumpusing2threads.NOTE:Progressinformationusesestimatedvaluesandmaynotbeaccurate.Writingschemametadata-doneWritingDDL-doneWritingtablemetadata-doneStartingdatadump100%(4rows/~4rows),0.00rows/s,0.00B/suncompressed,0.00B/scompressedDumpduration:00:00:00sTotalduration:00:00:00sSchemasdumped:1Tablesdumped:1Uncompresseddatasize:88bytesCompresseddatasize:61bytesCompressionratio:1.4Rowswritten:4Byteswritten:61bytesAverageuncompressedthroughput:88.00B/sAveragecompressedthroughput:61.00B/sMySQLlocalhost:3306sslJS>
Das Backup wird in folgendem Verzeichnis gespeichert, das nur für die Tabelle employees.salaries gilt:
[root@mysql80~]#ls-ltr/backupdir/employees/salariestotal48-rw-r-----. 1 root root 240 Feb 20 11:05 @.sql-rw-r-----. 1 root root 240 Feb 20 11:05 @.post.sql-rw-r-----. 1 root root 770 Feb 20 11:05 @.json-rw-r-----. 1 root root 236 Feb 20 11:05 employees.json-rw-r-----. 1 root root 478 Feb 20 11:05 employees.sql-rw-r-----. 1 root root 631 Feb 20 11:05 employees@salaries.json-rw-r-----. 1 root root 716 Feb 20 11:05 employees@salaries.sql-rw-r-----. 1 root root 8 Feb 20 11:05 employees@salaries@0.tsv.zst.idx-rw-r-----. 1 root root 8 Feb 20 11:05 employees@salaries@@1.tsv.zst.idx-rw-r-----. 1 root root 52 Feb 20 11:05 employees@salaries@0.tsv.zst-rw-r-----. 1 root root 9 Feb 20 11:05 employees@salaries@@1.tsv.zst-rw-r-----. 1 root root 266 Feb 20 11:05 @.done.json[root@mysql80~]#
In diesem Befehl kannst du den Sicherungsort und die Namen der zu sichernden Tabellen sowie die jeweiligen Schemanamen angeben.
Nachdem du die Datenbank gesichert hast, möchtest du die Daten in eine andere oder dieselbe Datenbank zurückspielen. Zu diesem Zweck enthält die MySQL Shell ein Dienstprogramm zum Laden von Daten. Mit diesem Dienstprogramm kannst du Daten aus einer Sicherungsdatei in eine Datenbank importieren.
Bevor du die Daten wiederherstellst, empfehlen wir dir, einen Trockenlauf durchzuführen, um die Sicherungsdatei zu überprüfen. Verwende diesen einfachen loadDump Befehl, um einen Trockenlauf durchzuführen:
MySQLlocalhost:3306sslJS>util.loadDump(\"/backuputildump/",{dryRun:true})LoadingDDLandDatafrom'/backuputildump/'using4threads.Openingdump...dryRunenabled,nochangeswillbemade.TargetisMySQL8.0.36.DumpwasproducedfromMySQL8.0.36Scanningmetadata-doneCheckingforpre-existingobjects...ExecutingcommonpreambleSQLExecutingDDL-doneExecutingviewDDL-doneStartingdataloadExecutingcommonpostambleSQL0%(0bytes/727bytes),0.00B/s,1/1tablesdoneRecreatingindexes-doneNodataloaded.0warningswerereportedduringtheload.MySQLlocalhost:3306sslJS>
Ebenso kannst du den Befehl (je nach Anforderung) vor dem Laden der Daten testen, um sicherzustellen, dass er richtig funktioniert. Das folgende Beispiel zeigt, wie du dieses Dienstprogramm für die Wiederherstellung von Backups verwenden kannst:
MySQLlocalhost:3306sslJS>util.loadDump(\"/backuputildump/",{progressFile:\"/backuputildump/backuplog.json",threads:4,backgroundThreads:4,maxBytesPerTransaction:"4096"})LoadingDDLandDatafrom'/backuputildump/'using4threads.Openingdump...TargetisMySQL8.0.36.DumpwasproducedfromMySQL8.0.36Scanningmetadata-doneCheckingforpre-existingobjects...ExecutingcommonpreambleSQLExecutingDDL-doneExecutingviewDDL-doneStartingdataloadExecutingcommonpostambleSQL100%(727bytes/727bytes),0.00B/s,1/1tablesdoneRecreatingindexes-done1chunks(20rows,727bytes)for1tablesin1schemaswereloadedin0sec(avgthroughput727.00B/s)0warningswerereportedduringtheload.MySQLlocalhost:3306sslJS>
Der vorangehende Befehl stellt die Daten aus der Sicherung des Verzeichnisses/backuputildump/ wieder her und verwendet während des Wiederherstellungsprozesses vier Threads und vier Hintergrundthreads. Außerdem wird eine Fortschrittsdatei unter /backuputildump/backuplog.json erstellt und die maximale Anzahl von Bytes pro Transaktion auf 4.096 gesetzt.
mysqldump
MySQL bietet das mysqldump Kommandozeilenprogramm zum Erstellen von logischen Datenbanksicherungen. In diesem Abschnitt erfahren wir, wie wir mysqldump effektiv nutzen können. Bevor wir uns mit dem Backup-Prozess beschäftigen, ist es wichtig, den Befehl mysqldump und seine Optionen zu verstehen. Der einfachste Weg, um auf diemysqldump Dokumentation zuzugreifen, ist die Kommandozeilenhilfe:
[root@mysql80~]#manmysqldump
Mit diesem Befehl wird das Handbuch mysqldump aufgerufen, das detaillierte Informationen über die Syntax, die Optionen und die Verwendung des Befehls enthält.
Sichern einzelner Tabellen
Die Sicherung von einzelnen Tabellen ist nützlich, wenn du nur bestimmte Datensätze wiederherstellen musst. Um mit dem Befehl mysqldump Backups von einzelnen Tabellen in einer Datenbank zu erstellen, verwendest du die folgende Syntax:
mysqldumpdatabase_nametable_name>backup_file.sql
Um zum Beispiel ein Backup der Tabelle city in der world
database zu erstellen, verwende den folgenden Befehl:
[root@mysql80backup]#mysqldump-uroot-pworldcity>city.sqlEnterpassword:[root@mysql80backup]#ls-ltrtotal176-rw-r--r--. 1 root root 179263 Feb 20 12:59city.sql[root@mysql80backup]#
Verwende die Option --where, um nur eine Teilmenge der Daten einer Tabelle zu sichern. Um zum Beispiel nur die Zeilen in der Tabelle city zu sichern, in der CountryCode 5 ist, führe folgenden Befehl aus:
[root@mysql80backup]#mysqldumpworld-uroot-pcity--where=\"CountryCode='USA'" > city_USA.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 14060 Feb 20 13:01city_USA.sql[root@mysql80backup]#
Verwende die Option --ignore-table, um bestimmte Tabellen von deiner Sicherung auszuschließen. Du kannst zum Beispiel den folgenden Befehl verwenden, um alle Tabellen in der Datenbank world mit Ausnahme der Tabelle city zu sichern:
[root@mysql80backup]#mysqldump-uroot-pworld--ignore-table=world.city > ignore_city_world.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 66071 Feb 20 13:08ignore_city_world.sql[root@mysql80backup]#
Um eine komplette Datenbanksicherung zu erstellen, verwendest du den Befehl mysqldump mit dem Datenbanknamen als Argument:
mysqldumpdatabase_name>backup_file.sql
Um zum Beispiel die Datenbank world zu sichern, verwende den folgenden Befehl:
[root@mysql80backup]#mysqldump-uroot-pworld>world.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 244085 Feb 20 13:05world.sql[root@mysql80backup]#
Sichern von mehreren Datenbanken
Um mehrere Datenbanken zu sichern, gibst du sie als kommagetrennte Liste an:
mysqldump--databasesdatabase1,database2>backup_file.sql
Um zum Beispiel die Datenbanken mytestdb sakila world_x und example_db1 zu sichern, führe den folgenden Befehl aus:
[root@mysql80backup]#mysqldump-uroot-p--databases mytestdb employeessakila>all_db_backup.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 3390832 Feb 20 13:27all_db_backup.sql[root@mysql80backup]#
Sichern aller Datenbanken
Um alle Datenbanken auf dem MySQL-Server zu sichern, verwendest du die Option --all-databases:
[root@mysql80backup]#mysqldump-uroot-p--all-databases>all_databases_backup.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 4937167 Feb 20 13:29all_databases_backup.sql[root@mysql80backup]#
Dadurch wird eine einzige Sicherungsdatei erstellt, die alle Datenbanken auf dem Server enthält.
Das Befehlszeilentool mysqldump erstellt ein logisches Backup einer Datenbank, indem es eine Reihe von SQL-Anweisungen generiert, mit denen die Datenbankobjekte und -daten neu erstellt werden können. Das folgende Beispiel erstellt ein Backup der Datenbank sakila mit verschiedenen Optionen für ein effizientes und konsistentes Backup:
[root@mysql80backup]#mysqldump-uroot-p--single-transaction --quick--lock-tables=false --routines --events --triggers--default-character-set=utf8mb4 sakila >backup.sqlEnterpassword:[root@mysql80backup]#ls-ltr-rw-r--r--. 1 root root 3397023 Feb 20 13:31backup.sql[root@mysql80backup]#
Schauen wir uns die einzelnen Optionen des Befehls an. Mit diesem Befehl wird mysqldump angewiesen, ein Backup der angegebenen Datenbank (dbname) zu erstellen und es in einer Datei namens backup.sql zu speichern:
--single-transaction-
Stellt sicher, dass die Sicherung konsistent ist, auch wenn zur gleichen Zeit andere Transaktionen in der Datenbank durchgeführt werden.
--quick-
Weist
mysqldumpan, eine Zeile nach der anderen abzurufen, anstatt die gesamte Ergebnismenge auf einmal abzurufen, was dazu beitragen kann, die Speichernutzung zu reduzieren. --lock-tables=false-
Stellt sicher, dass die Tabellen während des Backup-Prozesses nicht gesperrt werden, so dass die Datenbank weiterhin normal funktionieren kann.
--routines,--events, und--triggers-
Weist
mysqldumpan, gespeicherte Routinen, Ereignisse und Auslöser in das Backup aufzunehmen. --default-character-set=utf8mb4-
Ermöglicht es dir, die Verwendung des Zeichensatzes utf8mb4 in dem erzeugten SQL-Skript zu erzwingen. Dies kann nützlich sein, wenn du sicherstellen musst, dass das Backup alle in deiner Datenbank verwendeten Zeichen unterstützt, insbesondere wenn es Emojis oder andere Sonderzeichen enthält, die nicht in den Standardzeichensatz UTF-8 passen.
Wenn du ein logisches Backup mit mysqldump erstellt hast, kannst du es verwenden, um die Datenbank auf einem anderen Server neu zu erstellen oder um sie wiederherzustellen, wenn sie beschädigt wurde. Um ein logisches Backup wiederherzustellen, führst du einfach mit dem MySQL-Client die SQL-Anweisungen aus, die in der Backup-Datei enthalten sind.
Um einen Replikat-Knoten zu sichern und wiederherzustellen, kannst du entweder die --source-data oder--master-data Option verwenden. Verwenden Sie --source-data für MySQL 8.0.26 und neuer, oder verwenden Sie--master-data für frühere Versionen. Beide Optionen haben den gleichen Zweck, nämlich eine Dump-Datei zu erzeugen, die dazu verwendet werden kann, während der Replikation einen anderen Server als Replikat des Ausgangsservers einzurichten.
Wenn diese Optionen verwendet werden, enthält die resultierende Dump-Ausgabe eine CHANGE REPLICATION SOURCE TO -Anweisung (eingeführt in MySQL 8.0.23) oder eine CHANGE MASTER TO -Anweisung (verwendet vor MySQL 8.0.23). Diese Anweisung gibt die binären Log-Koordinaten (Dateiname und Position) des gedumpten Servers an, die angeben, von wo aus der Replikations-Quellserver nach dem Laden der Dump-Datei in dasReplikat mit der Replikation beginnen soll.
Wenn die Optionen --source-data oder --master-data auf 2 gesetzt sind, wird die Anweisung CHANGE REPLICATION SOURCE TO oder CHANGE MASTER TO in der Dumpdatei auskommentiert, so dass sie beim erneuten Laden der Dumpdatei nicht wirksam wird. Mit dem Optionswert 1 wird die Anweisung unkommentiert geschrieben und beim Neuladen der Dumpdatei wirksam. Wenn kein Optionswert explizit angegeben wird, wird der Standardwert 1 verwendet.
Einrichten eines Zeitplans für die Datensicherung
Erstelle ein Shell-Skript, das die MySQL-Sicherung mit Percona XtraBackup durchführt. Du kannst eine neue Datei mit einem beliebigen Texteditor (z.B. nano oder Vim) erstellen und sie mit der Erweiterung .sh speichern. In diesem Skript musst du die folgenden Befehle einfügen:
[root@mysql80backup]#catbackup_script.sh#!/bin/bash#SettheMySQLusernameandpasswordMYSQL_USER="root"MYSQL_PASSWORD='D@#NJU#$@MK28#nM'#SetthebackupdirectoryBACKUP_DIR="/root/backupdir/newbackup"#TakeafullbackupusingPerconaXtraBackupxtrabackup--backup --user=$MYSQL_USER --password=$MYSQL_PASSWORD--target-dir=$BACKUP_DIR/full_backup_$(date +%Y-%m-%d_%H-%M-%S)[root@mysql80backup]#
In diesem Skript musst du die Werte für MYSQL_USER, MYSQL_PASSWORD und BACKUP_DIR durch die entsprechenden Werte für dein System ersetzen. Vergewissere dich außerdem, dass du dem Skript Ausführungsrechte gibst, indem du den Befehl:
[root@mysql80backup]#chmod+xbackup_script.sh[root@mysql80backup]#ls-ltrtotal4-rwxr-xr-x.1rootroot344Feb2013:35backup_script.sh[root@mysql80backup]#
Der Befehl ./backup_script.sh führt ein Shell-Skript namens backup_script.sh aus, das sich im aktuellen Verzeichnis befindet:
[root@mysql80backup]#./backup_script.sh2024-02-20T13:42:56.095800-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--datadir=/var/lib/mysql2024-02-20T13:42:56.096132-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--user=root --password=* --socket=/var/lib/mysql/mysql.sock--backup=1 --user=root --password=*--target-dir=/root/backupdir/newbackup/full_backup_2024-02-20_13-42-55xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)24022013:42:56version_checkConnectingtoMySQLserverwithDSN'dbi:mysql:; mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock'as'root'(usingpassword:YES).24022013:42:56version_checkConnectedtoMySQLserver24022013:42:56version_checkExecutingaversioncheckagainsttheserver...24022013:42:56version_checkDone.2024-02-20T13:42:56.369830-00:000[Note][MY-011825][Xtrabackup]ConnectingtoMySQLserverhost:localhost,user:root,password:set,port:notset,socket:/var/lib/mysql/mysql.sock2024-02-20T13:42:59.708031-00:000[Note][MY-011825][Xtrabackup]Done:Writingfile/root/backupdir/newbackup/full_backup_2024-02-20_13-42-55/xtrabackup_info2024-02-20T13:43:00.711702-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(32549485)to(32549485)wascopied.2024-02-20T13:43:00.831082-00:000[Note][MY-011825][Xtrabackup]completedOK![root@mysql80backup]#
Um sicherzustellen, dass deine Datenbank regelmäßig gesichert wird, ist es wichtig, dass du einen Zeitplan für die Datensicherung erstellst. Um einen Zeitplan für die Datensicherung einzurichten, kannst du Cron-Aufträge oder andere Zeitplanungsprogramme verwenden. Hier ist ein Beispiel für einen Cron-Job, der jeden Tag um 2 Uhr nachts eine Sicherung durchführt:
crontab-e02***/root/backupdir/newbackup/backup_script.sh
Um einen Backup-Zeitplan einzurichten, kannst du eine Kombination aus crontab und der von dir gewählten Backup-Methode verwenden. Hier ist eine Beispielkonfiguration für die Einrichtung eines täglichen Sicherungsplans mit mysqldump:
-
Erstelle ein Backup-Verzeichnis, um die Backup-Dateien zu speichern:
[root@mysql80~]#sudomkdir-p/mnt/backups/mysql/[root@mysql80~]# -
Erteile dem Backup-Verzeichnis die erforderlichen Berechtigungen:
[root@mysql80~]#sudochown-Rmysql:mysql/mnt/backups/mysql/[root@mysql80~]# -
Verwende
sudo chmod -R 700 /mnt/backups/mysql/, um die Berechtigungen des Verzeichnisses /mnt/backups/mysql/ und aller seiner Unterverzeichnisse und Dateien zu ändern:[root@mysql80~]#sudochmod-R700/mnt/backups/mysql/[root@mysql80~]# -
Erstelle ein Shell-Skript:
[root@mysql80mysql]#cat/mnt/backups/mysql/backup_mysqldump.sh#!/bin/bash#Setthebackupdirectorybackup_dir="/mnt/backups/mysql"#SettheMySQLcredentialsmysql_user="root"mysql_password='D@#NJU#$@MK28#nM'#Createthebackupfilenamewithdatestampbackup_filename="$backup_dir/daily_backup_$(date +%Y%m%d).sql"#Executethemysqldumpcommandandsaveoutputtofilemysqldump--all-databases --user="$mysql_user" --password="$mysql_password">"$backup_filename"[root@mysql80mysql]# -
Teste das Skript, indem du es ausführst:
[root@mysql80mysql]#/mnt/backups/mysql/backup_mysqldump.sh/mnt/backups/mysql/daily_backup_20240220.sql[root@mysql80mysql]#ls-ltrtotal4828-rwxr-xr-x.1rootroot472Feb2014:18backup_mysqldump.sh-rw-r--r--. 1 root root 4937167 Feb 20 14:18 daily_backup_20240220.sql[root@mysql80mysql]# -
Öffne die crontab-Konfiguration:
crontab-e -
Füge die folgende Zeile in die Datei crontab ein, um ein tägliches Backup um 2 Uhr morgens zu planen:
02***/mnt/backups/mysql/backup_mysqldump.sh -
Speichere und schließe die crontab-Datei.
Wenn du diese Beispielkonfiguration befolgst, kannst du mit mysqldump einen täglichen Sicherungsplan für eine MySQL-Datenbank einrichten und sicherstellen, dass die Sicherungsdateien sicher gespeichert werden und bei Bedarf wiederhergestellt werden können. Die mitgelieferten Sicherungsskripte sind einfache Beispiele. Je nach deinen Anforderungen musst du eventuell Skripte mit Skriptsprachen wie Python oder einem Shell-Skript schreiben.
Auswahl der Sicherungsoptionen
Wenn du auf ein Backup erstellst, wähle verschiedene Backup-Optionen, um den Backup-Prozess anzupassen. Hier sind einige wichtige Backup-Optionen:
- Sicherungsart
-
Wähle entweder eine Vollsicherung oder eine inkrementelle Sicherung. Vollsicherungen erstellen eine vollständige Sicherung der Datenbank, während inkrementelle Sicherungen nur die Änderungen seit der letzten Sicherung sichern.
- Komprimierung
-
Komprimiere die Sicherungsdatei, um Speicherplatz zu sparen. XtraBackup,
mydumperundmysqldumpunterstützen die Komprimierung. - Verschlüsselung
-
Verschlüssele die Sicherungsdatei, um sensible Daten zu schützen. XtraBackup unterstützt die Verschlüsselung über die Option
--encrypt.
Überwachung des Backup-Prozesses
ist es wichtig, den Backup-Prozess zu überwachen, um sicherzustellen, dass er erfolgreich abgeschlossen wird. Hier sind einige Möglichkeiten, diesen Prozess zu überwachen:
-
Überprüfe das Backup-Logfile auf Fehler oder Warnungen.
-
Überprüfe die Größe der Sicherungsdatei, um sicherzustellen, dass sie nicht zu klein oder zu groß ist.
-
Um die Gültigkeit der Sicherungsdatei sicherzustellen, führe regelmäßig Wiederherstellungen durch, indem du die Produktionssicherung auf dem Testsystem verwendest.
Einrichten der Wiederherstellungsumgebung
Nachdem du unter eine Wiederherstellungsmethode ausgewählt hast, richte die Umgebung für den Wiederherstellungsprozess ein. Vergewissere dich, dass die Serverkonfiguration mit den Sicherungsdateien kompatibel ist, einschließlich der Version von MySQL und dem Speicherort des Datenverzeichnisses. Erstelle bei Bedarf eine neue MySQL-Instanz mit der gleichen Konfiguration wie die ursprüngliche Instanz.
Angenommen, das Backup wurde von einer MySQL 8.0.23 Instanz erstellt und du möchtest es auf einer neuen MySQL 8.0.25 Instanz wiederherstellen, kannst du die Umgebung für den Wiederherstellungsprozess mit den folgenden Schritten einrichten:
-
Installiere MySQL 8.0.25 auf dem Server, auf dem du die Datenbank wiederherstellen willst.
-
Beende den MySQL-Dienst mit dem Befehl
systemctl stop mysqld. -
Kopiere die Konfigurationsdatei von der ursprünglichen Instanz auf die neue Instanz, indem du einen Befehl wie
scpverwendest. -
Bearbeite die Konfigurationsdatei /etc/my.cnf so, dass sie mit der Konfiguration der ursprünglichen Instanz übereinstimmt, einschließlich des Speicherorts für das Datenverzeichnis.
-
Je nach Backup variiert der Wiederherstellungsprozess.
-
Starte den MySQL-Dienst mit dem Befehl
systemctl start mysqld.
Bei der Wahl einer Sicherungsmethode solltest du die Größe deiner Datenbank, die Anzahl der Datenänderungen und die RTO und RPO deines Unternehmens berücksichtigen. XtraBackup ist zum Beispiel eine effiziente Sicherungsmethode für große Datenbanken, die eine schnelle Wiederherstellungszeit benötigen, während mydumper im Vergleich zu XtraBackup mehr Zeit benötigt und mysqldump für kleinere Datenbanken geeignet ist, die sich längere Wiederherstellungszeiten leisten können.
Point-in-Time Recovery
Point-in-Time Recovery (PITR) ist eine Technik, mit der eine Datenbank zu einem bestimmten Zeitpunkt wiederhergestellt werden kann, in der Regel nach einer versehentlichen Löschung, Datenbeschädigung oder anderen Arten von Datenverlust. Dabei wird eine Datenbank in einem früheren Zustand wiederhergestellt, indem Transaktionsprotokolle wiedergegeben werden, die zu bestimmten Zeitpunkten erfasst wurden.
PITR ist notwendig, wenn du deine Datenbank zu einem bestimmten Zeitpunkt wiederherstellen musst. Wenn du zum Beispiel versehentlich wichtige Daten aus der Datenbank gelöscht hast und dies erst einige Stunden später bemerkst, kannst du mit PITR die Datenbank zu einem Zeitpunkt wiederherstellen, kurz bevor die Daten gelöscht wurden. Wenn die Datenbank beschädigt wurde, kannst du sie mit PITR zu einem Zeitpunkt wiederherstellen, bevor die Beschädigung aufgetreten ist.
PITR ist in den folgenden Situationen notwendig:
- Katastrophenhilfe
-
Wenn du durch eine Katastrophe wie einen Hardwareausfall, einen Stromausfall oder eine Naturkatastrophe einen Datenverlust erleidest, hilft dir PITR, die Daten zu einem bestimmten Zeitpunkt wiederherzustellen, bevor die Katastrophe eintrat.
- Menschliches Versagen
-
Wenn du versehentlich Daten löschst oder veränderst, kannst du mit PITR die Daten zu dem Zeitpunkt wiederherstellen, bevor der Fehler aufgetreten ist.
- Compliance
-
PITR wird oft benötigt, um Vorschriften wie den Health Insurance Portability and Accountability Act (HIPAA), den Sarbanes-Oxley Act (SOX) und die General Data Protection Regulation (GDPR) einzuhalten. Diese Vorschriften können verlangen, dass du Sicherungskopien von Daten aufbewahrst und in der Lage bist, die Daten zu einem bestimmten Zeitpunkt wiederherzustellen.
Wiederherstellung auf Instanz-Ebene
Mit dieser Wiederherstellungsmethode kannst du die gesamte MySQL-Instanz, einschließlich der Datenbanken, Tabellen, Schemas und Konfigurationen, in einem konsistenten Zustand wiederherstellen. Hier ist ein einfaches Beispiel für die Ausführung von PITR. Die Schritte können sich jedoch je nach verwendetem Backup-Tool (z.B. XtraBackup, MySQL Shell dump utility oder mydumper) sowie je nach Backup und Szenario der Produktionsumgebung unterscheiden, daher ist es wichtig, die entsprechenden Maßnahmen zu ergreifen.
Angenommen, du hast eine Datenbank für einen Online-Shop und hast versehentlich die Bestellung eines Kunden gelöscht. Du möchtest diese Bestellung wiederherstellen, aber keine Daten verlieren, die seit dem Löschen der Bestellung hinzugefügt wurden.
So kannst du mit PITR die Bestellung bis zu dem Moment wiederherstellen, bevor sie gelöscht wurde:
-
Um regelmäßige Sicherungen der Datenbank zu gewährleisten, ist es wichtig, diese in bestimmten Abständen zu planen. Eine Möglichkeit, eine vollständige Sicherung der Datenbank durchzuführen, ist der Befehl
xtrabackup, der bereits in "Percona XtraBackup" beschrieben wurde. -
Erstelle eine binäre Log-Sicherung der Datenbank mit dem Befehl
mysqlbinlog. Um regelmäßige Sicherungen zu gewährleisten, ist es wichtig, ein Skript zu erstellen und sie in bestimmten Abständen zu planen.Wenn du die binären Logdateien eines Servers mit
mysqlbinlogsicherst, musst du die tatsächlichen Dateinamen angeben, die auf dem Server existieren. Du kannst die AnweisungSHOW BINARY LOGSverwenden, um die aktuellen Namen zu sehen, wenn du dir nicht sicher bist, wie sie lauten:mysql>SHOWBINARYLOGS;+---------------+-----------+-----------+|Log_name|File_size|Encrypted|+---------------+-----------+-----------+|binlog.000001|35421|No||binlog.000002|12416|No||binlog.000003|52273|No|+---------------+-----------+-----------+Um ein statisches Backup von binlog.000001 bis binlog.000003 zu erstellen, kannst du einen der folgenden Befehle verwenden:
mysqlbinlog--read-from-remote-server --host=host_name --rawbinlog.000001binlog.000002binlog.000003mysqlbinlog--read-from-remote-server --host=host_name --raw--to-last-log binlog.000001Der erste Befehl listet explizit alle Dateinamen auf, während der zweite Befehl nur die erste Datei nennt und
--to-last-logverwendet, um die letzte Datei zu lesen. Ein Unterschied zwischen diesen Befehlen besteht darin, dass, wenn der Serverbinlog.000133 öffnet, bevormysqlbinlogdas Ende von binlog.000003 erreicht, der erste Befehl diese Datei nicht liest, der zweite Befehl aber schon.Um ein Live-Backup zu erstellen, bei dem
mysqlbinlogmit binlog.000001 beginnt, um bestehende Logdateien zu kopieren, und dann verbunden bleibt, um neue Ereignisse zu kopieren, sobald der Server sie erzeugt, kannst du Folgendes verwenden:mysqlbinlog--read-from-remote-server --host=host_name --raw--stop-never binlog.000001Mit
--stop-neverist es nicht notwendig, alle bereits vorhandenen binären Logdateien anzugeben. -
Stelle das vollständige Backup wieder her. (Siehe "Percona XtraBackup" für die Schritte, die erforderlich sind, um die von XtraBackup erstellte Vollsicherung wiederherzustellen).
-
Wende inkrementelle Backups an, um die Datenbank bis zum gewünschten Zeitpunkt wiederherzustellen:
mysqlbinlog--start-datetime='2023-03-01 12:00:00'--stop-datetime='2023-03-01 13:00:00' /var/log/mysql/binlog.000001 |mysql-uroot-pmydatabase
Hinweis
Dieses Beispiel demonstriert die Verwendung von XtraBackup. Je nachdem, welches Backup-System in der Produktion eingesetzt wird, hast du die Möglichkeit, entweder das MySQL Shell Dump Utility, mydumper, XtraBackup oder MySQL Enterprise Backup zu verwenden.
In diesem Beispiel stellen wir die Datenbank bis zu einer bestimmten Stunde am 1. März 2023 wieder her, also eine Stunde bevor die Bestellung gelöscht wurde.
Wenn du diese Schritte befolgst, kannst du den gelöschten Auftrag wiederherstellen, ohne dass Daten, die seit der Löschung hinzugefügt wurden, verloren gehen. PITR gibt dir mehr Kontrolle über deinen Datenwiederherstellungsprozess und kann ein wertvolles Hilfsmittel in Disaster-Recovery-Szenarien sein.
Wiederherstellung auf Tabellenebene
Um die Tabelle allein auf einer neuen Instanz wiederherzustellen, musst du sicherstellen, dass du eine gültige Sicherung der Tablespace-Dateien der Tabelle hast. Wenn du das getan hast, kannst du die folgenden Schritte ausführen, um eine Wiederherstellung auf Tabellenebene zu erstellen:
-
Verbinde dich mit der MySQL-Instanz, in der du die Tabelle wiederherstellen willst, und erstelle die Tabellenstruktur:
mysql>useadddb;Databasechangedmysql>CREATETABLE`authors`(->`id`intNOTNULLAUTO_INCREMENT,->`first_name`varchar(50)COLLATEutf8mb3_unicode_ciNOTNULL,->`last_name`varchar(50)COLLATEutf8mb3_unicode_ciNOTNULL,->`email`varchar(100)COLLATEutf8mb3_unicode_ciNOTNULL,->`birthdate`dateNOTNULL,->`added`timestampNOTNULLDEFAULTCURRENT_TIMESTAMP,->PRIMARYKEY(`id`)->)ENGINE=InnoDBAUTO_INCREMENT=72639469DEFAULTCHARSET=utf8mb4COLLATE=utf8mb4_0900_ai_ci;QueryOK,0rowsaffected,3warnings(0.03sec) -
Verwerfe den Tablespace der Tabelle
authors:mysql>selectcount(*)fromauthors;+----------+|count(*)|+----------+|0|+----------+1rowinset(0.01sec)mysql>ALTERTABLEauthorsDISCARDTABLESPACE;QueryOK,0rowsaffected(0.01sec)mysql>Wenn ein Tablespace verworfen wird, wird die Verbindung zwischen der Tabelle und dem zugrunde liegenden Tablespace aufgehoben. Die Tabellenstruktur und die Metadaten bleiben erhalten, aber die Tablespace-Dateien sind nicht mehr mit der Tabelle verbunden. Dieser Vorgang wird in der Regel durchgeführt, wenn du die Tablespace-Dateien durch einen anderen Satz von Dateien ersetzen oder die Tabelle aus einer Sicherung wiederherstellen willst.
-
Kopiere den Tablespace aus dem Backup:
root@UbuntuMysql8:~#scp/var/lib/mysql/adddb/authors.ibd172.31.84.219:/var/lib/mysql/adddb/authors.ibd100%544KB49.3MB/s00:00root@MyUbuntuMysql8:~# -
Ändere den Eigentümer der Datei authors.ibd, die sich im Verzeichnis /var/lib/mysql/adddb befindet. Der folgende Befehl weist den Benutzer und die Gruppe
mysqlals neue Eigentümer der Datei zu:[root@mysql80~]#chownmysql.mysql/var/lib/mysql/adddb/authors.ibd[root@mysql80~]# -
Importiere den Tablespace. Die Anweisung
ALTER TABLE authors IMPORT TABLESPACE;wird in MySQL verwendet, um einen Tablespace für die Tabelleauthorsinnerhalb der Datenbankadddbzu importieren. Mit diesem Befehl kannst du den Tablespace der Tabelleauthorswiederherstellen oder ersetzen, indem du eine zuvor exportierte oder gesicherte Tablespace-Datei(normalerweise mit der Erweiterung .ibd ) verwendest. Wenn du diese Anweisung ausführst, weist du MySQL an, die importierte Tablespace-Datei mit der Tabelleauthorsin der angegebenenDatenbank zu verknüpfen.Das Importieren des Tablespaces ermöglicht es dir, eine Tabelle zusammen mit ihren Daten- und Indexstrukturen wiederherzustellen oder zu migrieren. Er stellt die Verbindung zwischen der Tabellendefinition und der zugrundeliegenden Tablespace-Datei her, so dass die Tabelle innerhalb der MySQL-Datenbankinstanz vollständig zugänglich und betriebsbereit ist:
[root@mysql80mysql]#mysqlWelcometotheMySQLmonitor.Commandsendwith;or\g.mysql>mysql>ALTERTABLEadddb.authorsIMPORTTABLESPACE;QueryOK,0rowsaffected,1warning(0.05sec)mysql> -
Nach dem Import des Tablespaces für die Tabelle
authorsüberprüfe die Daten in der Tabelle:selectcount(id)fromadddb.authors;mysql>selectcount(id)fromadddb.authors;+-----------+|count(id)|+-----------+|6000|+-----------+1rowinset(0.03sec)
Nachdem du die Tabelle im Rahmen des PITR-Prozesses importiert hast, musst du die binlog-Backups verwenden, um die restlichen Daten vom Zeitpunkt des ersten Backups bis zum aktuellen Zeitpunkt wiederherzustellen. Dazu befolgst du die hier beschriebenen Schritte:
-
Kopiere das gewünschte binlog und erstelle den Index:
sudocporscpmysql-bin.*/data/sudochownmysql.mysql/data/mysql-bin.* -
Aktualisiere die Datei my.cnf:
relay-log=mysql-bin -
Bereite den Index vor, indem du die kopierten binlogs verwendest:
ls./mysql-bin.0*>mysql-bin.indexMit
IMPORT TABLESPACEhast du die Tabelle bereits aus dem bestehenden Backup importiert. -
Konfiguriere diese Tabelle als Dummy-Replikat:
mysql>CHANGEREPLICATIONSOURCETORELAY_LOG_FILE='mysql-bin.000001',RELAY_LOG_POS=4,SOURCE_HOST='dummy';QueryOK,0rowsaffected(0.08sec)mysql>CHANGEREPLICATIONFILTERREPLICATE_DO_TABLE=(adddb.authors);QueryOK,0rowsaffected(0.00sec) -
Validiere die Ausgabe und starte den Replikations-Thread (nur der SQL-Thread wird benötigt):
mysql>STARTREPLICASQL_THREAD;QueryOK,0rowsaffected(0.01sec)
PITR ist ein wichtiger Prozess, der das Fachwissen eines DBAs erfordert. In MySQL ermöglicht es dir, deine Datenbank in kritischen Situationen wie versehentlicher Datenlöschung, Datenbeschädigung, menschlichen Fehlern und Disaster Recovery zu einem bestimmten Zeitpunkt wiederherzustellen. Die geschickte Implementierung von PITR stellt die Datenintegrität sicher und minimiert mögliche Datenverluste in diesen kritischen Szenarien.
Indem du die binäre Protokollierung aktivierst, ein vollständiges Backup erstellst, das Backup an einem neuen Ort wiederherstellst, den Zeitpunkt der Wiederherstellung bestimmst und die Datenbank zu diesem Zeitpunkt wiederherstellst, kannst du die Datenintegrität sicherstellen und dich vor Datenverlust schützen.
Verwaltung von binären Protokollen
MySQL bietet einen robusten und zuverlässigen Logging-Mechanismus zur Nachverfolgung von Änderungen an der Datenbank, das so genannte Binary Logging. In diesem Abschnitt gehen wir auf die Bedeutung von Binärprotokollen ein und geben einen umfassenden Leitfaden zu deren Verwaltung.
Binäre Logs sind eine Art von Logdatei, die von MySQL erstellt wird, um alle Änderungen an der Datenbank aufzuzeichnen. Zu diesen Änderungen gehören Datenänderungen, Schemaänderungen und administrative Vorgänge wie die Benutzerverwaltung. Binäre Logs werden in einem binären Format gespeichert, was sie plattformunabhängig macht und eine einfache Replikation von Änderungen über mehrere Server hinweg ermöglicht.
Binäre Logs sind eine wichtige Komponente der HA- und Disaster-Recovery-Mechanismen von MySQL. Sie werden verwendet, um die Datenbank im Falle eines Serverabsturzes, einer Datenbeschädigung oder eines Benutzerfehlers wiederherzustellen. Binärprotokolle werden auch für die Replikation benötigt, um Datenänderungen zwischen Quell- und Replikat-Servern zu synchronisieren.
Aktivieren der binären Protokollierung
In früheren Versionen von MySQL musste die Binärprotokollierung manuell durch Angabe der Option --log-bin aktiviert werden, da sie standardmäßig deaktiviert war. Ab MySQL 8 ist die binäre Protokollierung jedoch standardmäßig aktiviert, unabhängig davon, ob die Option --log-bin angegeben ist.
Die einzige Ausnahme ist die manuelle Initialisierung des Datenverzeichnisses mit mysqld und der Option --initialize oder --initialize-insecure, die das binäre Logging standardmäßig deaktiviert. Um die binäre Protokollierung in diesem Fall zu aktivieren, muss die Option --log-bin angegeben werden. Durch die Aktivierung der binären Protokollierung wird die Systemvariable log_bin auf ON gesetzt, was den Status der binären Protokollierung auf dem Server anzeigt.
Um das binäre Logging zu aktivieren, füge die folgende Zeile in die MySQL-Konfigurationsdatei(my.cnf oder my.ini) ein:
[mysqld]log-bin=mysql-bin
Diese Konfiguration erstellt eine binäre Logdatei namensmysql-bin in dem in der MySQL-Konfigurationsdatei angegebenen Datenverzeichnis.
Konfigurieren der binären Protokollierung
MySQL bietet eine Reihe von Konfigurationsoptionen für die binäre Protokollierung. Diese Optionen können in der MySQL-Konfigurationsdatei oder dynamisch mit dem Befehl SET GLOBAL gesetzt werden. Einige der wichtigsten Konfigurationsoptionen für die binäre Protokollierung sind diefolgenden:
binlog_format-
Legt das Format fest, das für das binäre Logging verwendet wird. MySQL unterstützt drei Formate:
ROW,STATEMENT, undMIXED. Das Standardformat istROW. expire_logs_days-
Legt die Anzahl der Tage fest, nach denen die Binärprotokolle automatisch gelöscht werden sollen. Der Standardwert ist
0, was bedeutet, dass die Binärprotokolle nicht automatisch gelöscht werden. max_binlog_size-
Gibt die maximale Größe einer binären Logdatei an, bevor eine neue Datei erstellt wird. Der Standardwert ist 1.073.741.824 Bytes (1 GB).
binlog_row_image-
Legt das Format fest, das für die binäre Protokollierung von zeilenbasierten Ereignissen verwendet wird. MySQL unterstützt drei Formate:
FULL,MINIMALundNOBLOB. Das Standardformat istFULL.
Um zum Beispiel die Option binlog_format auf ROW zu setzen, fügen Sie die folgende Zeile in die MySQL-Konfigurationsdatei ein:
[mysqld]binlog_format=ROW
Löschen von Binärprotokollen
Im Laufe der Zeit können binäre Logs eine beträchtliche Menge an Speicherplatz verbrauchen. Um dies zu verhindern, bietet MySQL die Möglichkeit, alte binäre Logs zu löschen. Du kannst binäre Logs auf zwei Arten löschen: manuell oder automatisch.
Um binäre Logs manuell zu löschen, verwende den Befehl PURGE BINARY LOGS, der alle binären Logs bis einschließlich der Dateimysql-bin.000003 löscht:
PURGEBINARYLOGSTO'mysql-bin.000003';
Um binäre Logs automatisch zu löschen, setze die Option expire_logs_days in der MySQL-Konfigurationsdatei.
Hier entsprechen 604.800 Sekunden sieben Tagen (60 Sekunden/Minute × 60 Minuten/Stunde × 24 Stunden/Tag × 7 Tage). Bei dieser Konfiguration werden Binärprotokolle, die älter als sieben Tage sind, automatisch gelöscht:
[mysqld]binlog_expire_logs_seconds=604800;
Hier ist ein Beispiel dafür, wie du mit dem Befehl PURGE BINARY LOGS alte binäre Logdateien in MySQL löschen kannst:
-
Verwende den MySQL-Client, um dich mit dem MySQL-Server zu verbinden:
mysql-uroot-p -
Listet die derzeit verwendeten binären Logdateien auf:
mysql>SHOWBINARYLOGS;+---------------+-----------+-----------+|Log_name|File_size|Encrypted|+---------------+-----------+-----------+|binlog.000003|157|No||binlog.000004|201|No||binlog.000005|157|No||binlog.000006|201|No||binlog.000007|1357|No||binlog.000008|201|No||binlog.000009|157|No||binlog.000010|905|No||binlog.000011|1743|No||binlog.000012|2097859|No||binlog.000013|201|No||binlog.000014|1402|No|+---------------+-----------+-----------+12rowsinset(0.01sec)mysql>Dieser Befehl zeigt neben den aktuell verwendeten binären Logdateien auch deren Größe und Erstellungszeitpunkt an.
-
Verwende den Befehl
PURGE BINARY LOGS, um alte binäre Logdateien zu löschen. Um zum Beispiel alle binären Logdateien zu löschen, die älter als sieben Tage sind, verwendest du den folgenden Befehl:mysql>PURGEBINARYLOGSBEFOREDATE_SUB(NOW(),INTERVAL7DAY);QueryOK,0rowsaffected(0.02sec)Du kannst das Intervall nach Bedarf anpassen, um Dateien zu löschen, die älter oder neuer als eine bestimmte Anzahl von Tagen sind.
-
Überprüfe, ob die alten binären Logdateien gelöscht wurden, indem du den Befehl
SHOW BINARY LOGSerneut ausführst:mysql>SHOWBINARYLOGS;+---------------+-----------+-----------+|Log_name|File_size|Encrypted|+---------------+-----------+-----------+|binlog.000013|201|No||binlog.000014|1402|No|+---------------+-----------+-----------+2rowsinset(0.00sec)Jetzt siehst du die aktuell verwendeten binären Logdateien, mit Ausnahme der Dateien, die mit dem Befehl
PURGE BINARY LOGSgelöscht wurden.
Mit dem Befehl PURGE BINARY LOGS kannst du deine binären Logdateien unter Kontrolle halten und verhindern, dass sie mit der Zeit zu viel Speicherplatz verbrauchen. Binäre Logdateien sind eine wichtige Komponente der HA- und Disaster-Recovery-Mechanismen von MySQL. Sie bieten eine zuverlässige Möglichkeit, Änderungen an der Datenbank zu verfolgen und ermöglichen eine einfache Replikation der Änderungen über mehrere Server hinweg. Wenn du die in diesem Abschnitt beschriebenen Richtlinien befolgst, kannst du sicherstellen, dass deine Binärprotokolle richtig konfiguriert undverwaltet werden.
Bewährte Methoden für Backup und Wiederherstellung
In der Welt der Datenbanken sind Sicherung und Wiederherstellung unerlässlich, um die Integrität der Daten zu gewährleisten. Ein einziger Datenbankausfall kann zum Verlust wichtiger Daten führen, was den Geschäftsbetrieb beeinträchtigen kann. Deshalb ist es wichtig, bewährte Methoden für die Sicherung und Wiederherstellung in MySQL zu implementieren.
Regelmäßige Backups sind wichtig, um sicherzustellen, dass deine Daten sicher und wiederherstellbar sind. Der Zeitplan für regelmäßige Sicherungen hängt von der Größe deiner Daten und der Änderungsrate der Daten ab. Als Faustregel gilt, dass du bei Datenbanken mit hohem Transaktionsvolumen täglich, bei Datenbanken mit geringerem Datenaustausch wöchentlich oder monatlich Sicherungen durchführen solltest. Hier sind einige weitere bewährte Methoden zur Datensicherung:
- Erstelle eine Backup-Strategie
-
Lege eine Backup-Strategie fest, die deine Anforderungen an die Wiederherstellung erfüllt, z. B. die Häufigkeit der Backups, die Art der Backups (vollständig oder inkrementell) und die Aufbewahrungszeiträume.
- Sichern von einem Replikat-Knoten
-
Es wird empfohlen, ein MySQL-Backup von einem Replikat-Knoten zu erstellen, da dies die Belastung des primären Knotens reduziert und eine konsistente Sicherung gewährleistet. Durch die Sicherung von einem Replikat-Knoten wird der primäre Knoten nicht mit zusätzlicher Arbeitslast belastet, die die Leistung des Live-Systems beeinträchtigen kann. Da der Replikat-Knoten mit dem Primärknoten synchronisiert ist, garantiert er außerdem die Konsistenz der Sicherung und verringert das Risiko von, dass Daten beschädigt werden oder verloren gehen. Insgesamt ist die Sicherung von einem Replikat-Knoten eine bewährte Methode für MySQL-DBAs, um die Verfügbarkeit und Integrität ihrer Daten sicherzustellen.
Die Bestätigung der Integrität der Daten im Replikat ist ebenfalls sehr wichtig und wird nicht unbedingt nur durch die laufende Replikation gewährleistet. Es ist die Aufgabe des DBAs sicherzustellen, dass es sich um eine exakte Kopie handelt, indem er Tools wie
pt-table-checksumeinsetzt. - Sichern Sie das MySQL-Binlog oder Binär-Log
-
Ein Binärlog ist eine Protokolldatei, die alle Änderungen an einer Datenbank aufzeichnet, einschließlich Einfügungen, Aktualisierungen und Löschungen. Die Sicherung des MySQL-Binlogs ist wichtig, da es dabei hilft, Daten von einem bestimmten Zeitpunkt aus wiederherzustellen, was in verschiedenen Szenarien nützlich sein kann, z. B. bei der Wiederherstellung im Katastrophenfall, bei der Replikation und bei der Rechnungsprüfung. Im Falle einer Katastrophe, z. B. eines Hardwareausfalls oder einer Datenbeschädigung, kann das Binlog verwendet werden, um die Datenbank zu einem bestimmten Zeitpunkt vor dem Eintreten der Katastrophe wiederherzustellen und so den Datenverlust zu minimieren. Außerdem ist die Sicherung des Binlogs wichtig für die Replikation, da es die Synchronisation der Replikat-Datenbanken mit der primären Datenbank ermöglicht. Schließlich kann das Binlog für Prüfungszwecke verwendet werden, indem es eine detaillierte Aufzeichnung aller Änderungen an der Datenbank liefert, was für die Einhaltung von Vorschriften und die Sicherheit nützlich sein kann. Insgesamt ist die Sicherung des MySQL-Binlogs eine wichtige Praxis, um die Verfügbarkeit, Integrität und Sicherheit der Daten zu gewährleisten.
- MySQL Enterprise Backup verwenden
-
MySQL Enterprise Backup ist eine kommerzielle Backup-Lösung, die unternehmenstaugliche Sicherungs- und Wiederherstellungsfunktionen für MySQL-Datenbanken bietet. Sie bietet schnelle, zuverlässige und skalierbare Backups sowie Unterstützung für PITR und partielleBackups.
- Percona XtraBackup verwenden
-
XtraBackup ist ein beliebtes Open-Source-Tool zum Sichern und Wiederherstellen von MySQL-Datenbanken. Einer der Hauptgründe für den Einsatz von XtraBackup ist, dass es Hot Backups von InnoDB- und XtraDB-Speicher-Engines durchführt, d.h. es kann Backups erstellen, ohne die Datenbank zu sperren oder Ausfallzeiten zu verursachen. XtraBackup bietet noch weitere nützliche Funktionen wie parallele Komprimierung und inkrementelle Backups, die die Backup-Leistung und -Effizienz weiter verbessern. Außerdem ist XtraBackup in hohem Maße anpassbar, so dass DBAs die Backups auf ihre speziellen Bedürfnisse zuschneiden können. Insgesamt ist XtraBackup ein zuverlässiges und flexibles Werkzeug, das den Sicherungs- und Wiederherstellungsprozess für MySQL-Datenbanken vereinfacht.
- MySQL Shell dump utility
-
Der MySQL-Shell-Dump ist ein Kommandozeilen-Tool, das zur Sicherung und Wiederherstellung von MySQL-Datenbanken verwendet wird. Einer der Hauptvorteile des MySQL Shell dump ist, dass es eine umfassendere Sicherungslösung bietet als herkömmliche Sicherungsmethoden. Mit dem MySQL Shell dump ist es möglich, nicht nur das Datenbankschema und die Daten, sondern auch gespeicherte Routinen, Trigger und Benutzerkonten zu sichern. Der MySQL Shell dump unterstützt auch parallele Backups und ermöglicht so schnellere und effizientere Backups großer Datenbanken. Außerdem ist der MySQL Shell dump sehr anpassungsfähig und ermöglicht es DBAs, Backup-Optionen wie Komprimierung und selektive Backups festzulegen. Insgesamt ist MySQL Shell dump ein leistungsstarkes und flexibles Werkzeug, das den Sicherungs- und Wiederherstellungsprozess für MySQL-Datenbanken vereinfacht.
- Verwende
mysqldumpfür kleine Datenbanken -
Für kleine Datenbanken ist
mysqldumpeine zuverlässige und kostengünstige Backup-Lösung. Sie kann MySQL-Datenbanken im SQL-Format sichern, so dass sie im Falle eines Datenverlusts leicht wiederhergestellt werden können. - Teste deine Backups
-
Es reicht nicht aus, Daten zu sichern, wenn du nicht überprüft hast, ob die Sicherungen wiederherstellbar sind. Deshalb ist es wichtig, deine Backups regelmäßig zu testen, um sicherzustellen, dass sie im Falle einer Katastrophe wiederhergestellt werden können. Du kannst deine Backups testen, indem du sie in einer Testumgebung wiederherstellst und die Daten auf Richtigkeit und Konsistenz überprüfst.
- Speichere deine Backups offsite
-
Die Auslagerung von Backups ist wichtig für den Fall einer Katastrophe wie Feuer, Diebstahl oder Naturkatastrophen, die dein primäres Rechenzentrum betreffen könnten. Wenn du die Backups an einem anderen Ort aufbewahrst, ist sichergestellt, dass sie sicher und wiederherstellbar sind. Du kannst Backups in verschiedenen Cloud-Speicherlösungen wie Amazon Simple Storage Service (S3), Google Cloud Storage oder Microsoft Azure speichern oder physische Speichergeräte wie Bänder oder externe Festplatten verwenden.
- Nutze die Speicherung in der Cloud
-
Cloud-Provider wie Amazon S3, Google Cloud Storage und Microsoft Azure bieten zuverlässige und sichere Möglichkeiten für die externe Speicherung deiner Backups. Wenn du S3 nutzt, kannst du die Amazon Web Services (AWS) CLI verwenden, um den Sicherungs- und Wiederherstellungsprozess zu automatisieren. Du kannst zum Beispiel den folgenden Befehl verwenden, um dein Backup in den S3 Bucket mit dem Namenmybucket/backups hochzuladen:
awss3cp/backup/full/backup-to-images3://mybucket/backups/ - Sichere Transportprotokolle verwenden
-
Verwende sichere Transportprotokolle wie SSL oder Secure Shell (SSH), um deine Backups vor unberechtigtem Zugriff zu schützen. Die AWS CLI verwendet SSL als Standard-Kommunikationsprotokoll, und für jede SSL-Verbindung werden SSL-Zertifikate von der AWS CLIüberprüft. Mit dem folgenden Befehl wird dein Backup-Image über SSL an S3 übertragen:
awss3cp/backup/full/backup-to-images3://mybucket/backups/--sse
Der Parameter --sse legt die serverseitige Verschlüsselung für ein Objekt in S3 fest und kann die Werte AES256 oder aws:kms annehmen. Wird kein Wert für den Parameter angegeben, wird die Standardverschlüsselung AES256 verwendet.
Verschlüsselung zum Schutz deiner Backups
Die Verschlüsselung von Backups sorgt dafür, dass sie sicher und vor unberechtigtem Zugriff geschützt sind. Du kannst verschiedene Verschlüsselungsmethoden verwenden, z. B. symmetrische oder asymmetrische Verschlüsselung, um deine Backups zu verschlüsseln. MySQL bietet Verschlüsselungsoptionen wie die Option --ssl* fürmysqldump oder die Option --encrypt für MySQL Enterprise Backup. Hier sind einige bewährte Methoden für die Verschlüsselung deiner Backups:
- MySQL Enterprise Backup verwenden
-
MySQL Enterprise Backup bietet Verschlüsselungsfunktionen, mit denen du deine Backups mit AES-256 verschlüsseln kannst. Außerdem unterstützt es die Verwendung von Schlüsselverwaltungssystemen wie Oracle Key Vault.
- Verschlüsselungstools von Drittanbietern verwenden
-
Du kannst Verschlüsselungstools von Drittanbietern wie GNU Privacy Guard (GnuPG) oder OpenSSL verwenden, um deine Backups zu verschlüsseln, bevor du sie außer Haus speicherst.
- Verschlüsselungs-Plug-ins verwenden
-
MySQL Enterprise Backup bietet Verschlüsselungs-Plug-ins, mit denen du deine Backups verschlüsseln kannst. Du kannst zum Beispiel das AES-256 Verschlüsselungs-Plug-in verwenden, um deine Backups mit dem folgenden Befehl zu verschlüsseln:
mysqlbackup--backup-dir=/backup/full--backup-image=/backup/full/backup-to-image \--encrypt=AES256 --key-file=/path/to/keyfile --host=mydb.example.com \--port=3306 --user=admin --password backup-to-image
Dieser Befehl verschlüsselt dein Backup-Image mit AES-256-Verschlüsselung und der Schlüsseldatei, die sich unter /path/to/key befindet.
XtraBackup Verschlüsselung
Da MySQL 8 und Percona Server 8.0 von Percona XtraBackup 2.4.x nicht unterstützt werden, musst du Percona XtraBackup 8.0.x für Backups und Wiederherstellungen verwenden. In diesem Abschnitt findest du die aktualisierten Schritte zur Installation von Percona XtraBackup 8.0.x.
Wie bereits erwähnt, musst du das Percona-Repository zur Liste der verfügbaren Repositories in deinem Paketmanager hinzufügen. Öffne ein Terminal oder eine Eingabeaufforderung und führe die Befehle in diesem Abschnitt aus.
Für Debian/Ubuntu lädst du die Debian-Paketdatei mit wget herunter:
root@MyUbuntuMysql8:~# wget https://repo.percona.com/apt/p ercona-release_latest.generic_all.deb --2024-02-20 14:57:01-- https://repo.percona.com/apt/ percona-release_latest.generic_all.deb Resolving repo.percona.com (repo.percona.com)... 147.135.54.159, Length: 11804 (12K) [application/x-debian-package] Saving to: 'percona-release_latest.generic_all.deb' percona-release_latest.generic_all.deb 100% [============================================>] 11.53K --.-KB/s in 0s 2024-02-20 14:57:01 (196 MB/s) - 'percona-release_latest.generic_all.deb' saved [11804/11804] root@MyUbuntuMysql8:~#
Der Befehl sudo dpkg wird verwendet, um das Debian-Paket zu installieren:
root@MyUbuntuMysql8:~#sudodpkg-ipercona-release_latest.generic_all.debSelectingpreviouslyunselectedpackagepercona-release.<*>Alldone!*EnablingthePerconaReleaserepository<*>Alldone!Forexample,toenablethePerconaServer8.0repositoryuse:percona-releasesetupps80Note:Toavoidconflictswitholderproductversions,thepercona-releaseroot@MyUbuntuMysql8:~#
Aktualisiere die Paketlisten für verfügbare Software-Repositories:
root@MyUbuntuMysql8:~# sudo apt-get update Hit:1 http://us-east-1.ec2.archive.ubuntu.com/ubuntu jammy InRelease Get:2 http://us-east-1.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] Hit:3 http://us-east-1.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease Get:11 http://repo.percona.com/prel/apt jammy/main amd64 Packages [415 B] Fetched 3088 kB in 2s (1713 kB/s) Reading package lists... Done root@MyUbuntuMysql8:~#
Um die Version 80 des Percona XtraBackup-Tools auf einem System zu installieren, führe den folgenden Befehl aus:
root@MyUbuntuMysql8:~#sudoapt-getinstallpercona-xtrabackup-80Readingpackagelists...DoneBuildingdependencytree...DoneReadingstateinformation...DoneThefollowingadditionalpackageswillbeinstalled:libcurl4-openssl-devlibev4Suggestedpackages:libcurl4-doclibidn11-devlibkrb5-devlibldap2-devlibrtmp-devlibssh2-1-devlibssl-devpkg-configzlib1g-devThefollowingNEWpackageswillbeinstalled:libcurl4-openssl-devlibev4percona-xtrabackup-80Processingtriggersforlibc-bin(2.35-0ubuntu3.6)...Scanningprocesses...Runningkernelseemstobeup-to-date.Restartingservices...Servicerestartsbeingdeferred:systemctlrestartsystemd-logind.serviceNocontainersneedtoberestarted.Nousersessionsarerunningoutdatedbinaries.NoVMguestsarerunningoutdatedhypervisor(qemu)binariesonthishost.root@MyUbuntuMysql8:~#
Überprüfe die Version des installierten XtraBackup:
root@MyUbuntuMysql8:~#xtrabackup--version2024-02-20T15:02:37.633932-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_directories=/var/lib/user_defined_general_tablespacextrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)root@MyUbuntuMysql8:~#
Um ein verschlüsseltes Backup mit Percona XtraBackup zu erstellen, kannst du die folgenden Schritte ausführen:
-
Bestimme den Verschlüsselungsalgorithmus. Percona XtraBackup unterstützt drei Verschlüsselungsalgorithmen: AES-128, AES-192 und AES-256. Wähle den Algorithmus, den du für die Verschlüsselung verwenden möchtest.
-
Erstelle einen Verschlüsselungscode. Du hast zwei Optionen, um den Verschlüsselungscode beim Erstellen von verschlüsselten Backups anzugeben:
xtrabackup --encrypt-keyundxtrabackup--encrypt-key-file. Hier ist ein Beispielbefehl, um einen Verschlüsselungsschlüssel zu erzeugen:root@MyUbuntuMysql8:~#opensslrand-base6424P/Fu9cZo9gzkzpmtvUKFku3u4ONTrj5Zroot@MyUbuntuMysql8:~#Hier ist ein Beispiel für den XtraBackup-Befehl, der die Option
xtrabackup --encrypt-keyverwendet:root@MyUbuntuMysql8:~#mkdir/root/backups/root@MyUbuntuMysql8:~#xtrabackup--backup --target-dir=/root/backups/--encrypt=AES256 --encrypt-key=""P/Fu9cZo9gzkzpmtvUKFku3u4ONTrj5Z""2024-02-20T15:04:59.723781-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_directories=/var/lib/user_defined_general_tablespace2024-02-20T15:04:59.724228-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--ssl-mode=REQUIRED --ssl-cert=/var/lib/mysql/client-cert.pem--ssl-key=/var/lib/mysql/client-key.pem --backup=1--target-dir=/root/backups/ --encrypt=AES256 --encrypt-key=*xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)24022015:04:59version_checkConnectingtoMySQLserverwithDSN'dbi:mysql:; mysql_read_default_group=xtrabackup'(usingpassword:NO).24022015:05:00version_checkConnectedtoMySQLserver24022015:05:00version_checkExecutingaversioncheckagainsttheserver... -
Überprüfe nach Abschluss des Backups das Protokoll, um den erfolgreichen Abschluss zu bestätigen. Du solltest ein ähnliches Protokoll wie dieses erhalten:
2024-02-20T15:05:03.706837-00:000[Note][MY-011825][Xtrabackup]Encrypting/root/backups/xtrabackup_info.xbcrypt2024-02-20T15:05:03.707047-00:000[Note][MY-011825][Xtrabackup]Done:Encryptingfile/root/backups/xtrabackup_info.xbcrypt2024-02-20T15:05:04.717140-00:000[Note][MY-011825][Xtrabackup]Transactionlogoflsn(42914523)to(42914533)wascopied.2024-02-20T15:05:04.826343-00:000[Note][MY-010733][Server]Shuttingdownplugin'keyring_file'2024-02-20T15:05:04.828326-00:000[Note][MY-010733][Server]Shuttingdownplugin'daemon_keyring_proxy_plugin'2024-02-20T15:05:04.831369-00:000[Note][MY-011825][Xtrabackup]completedOK!root@MyUbuntuMysql8:~#
Im Backup-Verzeichnis liegen alle Dateien im .xbcrypt-Format vor und stellen verschlüsselte Versionen der MySQL-Datenbankdateien dar:
root@MyUbuntuMysql8:~#ls-ltr/root/backups/total76232-rw-r----- 1 root root 12600576 Feb 20 15:05 ibdata1.xbcryptdrwxr-x--- 2 root root 4096 Feb 20 15:05 sysdrwxr-x--- 2 root root 4096 Feb 20 15:05 mydatabasedrwxr-x--- 2 root root 4096 Feb 20 15:05 mytestschemadrwxr-x--- 2 root root 4096 Feb 20 15:05 unencryptedschema-rw-r----- 1 root root 114872 Feb 20 15:05user_defined_general_tablespace.ibd.xbcrypt-rw-r----- 1 root root 114872 Feb 20 15:05user_defined_general_tablespace_1.ibd.xbcryptdrwxr-x--- 2 root root 4096 Feb 20 15:05 encryptedschemadrwxr-x--- 2 root root 4096 Feb 20 15:05 mytestdrwxr-x--- 2 root root 4096 Feb 20 15:05 mytestdbdrwxr-x--- 2 root root 4096 Feb 20 15:05 adddb-rw-r----- 1 root root 31501440 Feb 20 15:05 mysql.ibd.xbcrypt-rw-r----- 1 root root 16800768 Feb 20 15:05 undo_002.xbcrypt-rw-r----- 1 root root 16800768 Feb 20 15:05 undo_001.xbcryptdrwxr-x--- 2 root root 12288 Feb 20 15:05 performance_schemadrwxr-x--- 2 root root 4096 Feb 20 15:05 testdrwxr-x--- 2 root root 4096 Feb 20 15:05 mytestdb_innodrwxr-x--- 2 root root 4096 Feb 20 15:05 mysqldrwxr-x--- 2 root root 4096 Feb 20 15:05 d1-rw-r----- 1 root root 249 Feb 20 15:05 binlog.000076.xbcrypt-rw-r----- 1 root root 108 Feb 20 15:05 binlog.index.xbcrypt-rw-r----- 1 root root 110 Feb 20 15:05 xtrabackup_binlog_info.xbcrypt-rw-r----- 1 root root 2744 Feb 20 15:05 xtrabackup_logfile.xbcrypt-rw-r----- 1 root root 134 Feb 20 15:05 xtrabackup_checkpoints-rw-r----- 1 root root 4600 Feb 20 15:05 ib_buffer_pool.xbcrypt-rw-r----- 1 root root 567 Feb 20 15:05 backup-my.cnf.xbcrypt-rw-r----- 1 root root 597 Feb 20 15:05 xtrabackup_info.xbcrypt-rw-r----- 1 root root 131 Feb 20 15:05 xtrabackup_tablespaces.xbcryptroot@MyUbuntuMysql8:~#
Verschlüsselte Backups entschlüsseln
Die Option --decrypt in Percona XtraBackup ermöglicht die Entschlüsselung von Backups:
root@MyUbuntuMysql8:~/backups/mysql#xtrabackup--decrypt=AES256--encrypt-key="P/Fu9cZo9gzkzpmtvUKFku3u4ONTrj5Z" --target-dir=/root/backups/--remove-original2024-02-20T15:12:08.321590-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_directories=/var/lib/user_defined_general_tablespace2024-02-20T15:12:08.322065-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--ssl-mode=REQUIRED --ssl-cert=/var/lib/mysql/client-cert.pem--ssl-key=/var/lib/mysql/client-key.pem --decrypt=AES256 --encrypt-key=*--target-dir=/root/backups/ --remove-original=1xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-20T15:12:08.354574-00:000[Note][MY-011825][Xtrabackup]decrypting./performance_schema/replication_conn_162.sdi.xbcrypt
Überprüfe nach dem Entschlüsselungsprozess das Protokoll, um sicherzustellen, dass er erfolgreich abgeschlossen wurde. Du solltest ein Protokoll sehen, das diesem ähnelt:
2024-02-20T15:12:09.727703-00:000[Note][MY-011825][Xtrabackup]decrypting./xtrabackup_binlog_info.xbcrypt2024-02-20T15:12:09.731566-00:000[Note][MY-011825][Xtrabackup]removing./xtrabackup_binlog_info.xbcrypt2024-02-20T15:12:09.733903-00:000[Note][MY-011825][Xtrabackup]completedOK!root@MyUbuntuMysql8:~/backups/mysql#
Verwende eine sichere Schlüsselverwaltungslösung, um deine Verschlüsselungsschlüssel zu speichern und zu verwalten. Du kannst zum Beispiel den AWS Key Management Service (KMS) verwenden, um deine Verschlüsselungsschlüssel zu erzeugen und zu verwalten.
Vorbereiten der entschlüsselten Backups
Der Befehl xtrabackup --prepare wird verwendet, um die Sicherungsdateien im angegebenen Verzeichnis vorzubereiten:
root@MyUbuntuMysql8:~#xtrabackup--prepare --target-dir=/root/backups/2024-02-20T15:15:10.126368-00:000[Note][MY-011825][Xtrabackup]recognizedserverarguments:--innodb_checksum_algorithm=crc32 --innodb_log_checksums=1--innodb_data_file_path=ibdata1:12M:autoextend --innodb_log_file_size=50331648--innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2--server-id=0 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0--innodb_undo_log_encrypt=02024-02-20T15:15:10.126706-00:000[Note][MY-011825][Xtrabackup]recognizedclientarguments:--prepare=1 --target-dir=/root/backups/xtrabackupversion8.0.35-30basedonMySQLserver8.0.35Linux(x86_64)(revisionid:6beb4b49)2024-02-20T15:15:10.127029-00:000[Note][MY-011825][Xtrabackup]cdto/root/backups/2024-02-20T15:15:10.127237-00:000[Note][MY-011825][Xtrabackup]Thistargetseemstobenotpreparedyet.
Überprüfe nach Abschluss des Vorbereitungsprozesses das Protokoll, um die erfolgreiche Ausführung zu bestätigen:
2024-02-20T15:15:12.162295-00:000[Note][MY-012980][InnoDB]Shutdowncompleted;logsequencenumber429148382024-02-20T15:15:12.166062-00:000[Note][MY-010733][Server]Shuttingdownplugin'keyring_file'2024-02-20T15:15:12.166261-00:000[Note][MY-010733][Server]Shuttingdownplugin'daemon_keyring_proxy_plugin'2024-02-20T15:15:12.166814-00:000[Note][MY-011825][Xtrabackup]completedOK!root@MyUbuntuMysql8:~#
mysqldump Verschlüsselung
mysqldump Verschlüsselung sichert Datenbanksicherungen, indem sie die Daten in einen unlesbaren Chiffretext umwandelt und so den unbefugten Zugriff verhindert. Ein Entschlüsselungsschlüssel wird benötigt, um den verschlüsselten Text wieder in seine ursprüngliche, lesbare Form zu bringen.
Mit dem Befehl mysqldump kannst du ein Backup einer MySQL-Datenbank namens mytestdb erstellen und in einer Datei namens backup.sql speichern:
root@MyUbuntuMysql8:~/backups#mysqldump-uroot-pmytestdb>backup.sqlEnterpassword:root@MyUbuntuMysql8:~/backups#ls-ltrtotal8-rw-r--r-- 1 root root 5714 Feb 20 15:22 backup.sqlroot@MyUbuntuMysql8:~/backups#
Nachdem du das Backup erstellt hast, verschlüsselst du mit dem Befehl openssl eine Datei namens backup.sql mit dem Verschlüsselungsalgorithmus AES-256-CBC:
root@MyUbuntuMysql8:~/backups#opensslaes-256-cbc-salt-inbackup.sql-outbackup.sql.encenterAES-256-CBCencryptionpassword:Verifying-enterAES-256-CBCencryptionpassword:root@MyUbuntuMysql8:~/backups#
Dieser Code erstellt eine Sicherungskopie der Datenbank mydatabase mit dem Befehlmysqldump und verschlüsselt sie mit OpenSSL mit dem AES-256-CBC-Algorithmus.
Um das Backup zu entschlüsseln, kannst du den folgenden Befehl verwenden:
root@MyUbuntuMysql8:~/backups#opensslaes-256-cbc-d-inbackup.sql.enc-outbackup.sqlenterAES-256-CBCdecryptionpassword:root@MyUbuntuMysql8:~/backups#
Dieser Code entschlüsselt die Sicherungsdatei backup.sql.enc mit dem AES-256-CBC-Algorithmus und gibt die entschlüsselte Datei in backup.sql aus.
Fazit
Sicherung und Wiederherstellung sind in jeder MySQL-Umgebung von entscheidender Bedeutung. Wenn du die Richtlinien in diesem Kapitel befolgst, kannst du sicherstellen, dass deine Daten geschützt sind und im Falle einer Katastrophe leicht wiederhergestellt werden können.
Get Hands-On MySQL-Verwaltung now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
