Wesentliche MySQL-Backup-Strategien: Die Wahl des richtigen Ansatzes für Ihre Daten
Vergleichen Sie logische, physische und binäre Log-Backups von MySQL, um eine Wiederherstellungsstrategie zu wählen, die Ihren RTO- und RPO-Anforderungen entspricht.
Wichtige MySQL-Backup-Strategien: Den richtigen Ansatz für Ihre Daten wählen
Ihre MySQL-Backup-Strategie ist nur dann gut, wenn Sie unter Druck daraus wiederherstellen können. Eine Dump-Datei, ein Dateisystem-Snapshot und ein physisches Backup lösen unterschiedliche Wiederherstellungsprobleme. Die richtige Wahl hängt daher von Ihrer Datengröße, Ihrer Ausfalltoleranz und davon ab, wie viele Daten Sie sich leisten können zu verlieren.
Warum MySQL-Backups einen Wiederherstellungsplan benötigen
Backups schützen Sie nicht nur vor Festplattenausfällen. Sie helfen auch dabei, sich von Anwendungsfehlern, fehlerhaften Bereitstellungen, versehentlichen Löschungen, Ransomware und regionalen Ausfällen zu erholen.
Beginnen Sie mit zwei Zielen:
- RTO: Wie lange darf die Datenbank während der Wiederherstellung ausfallen?
- RPO: Wie viele aktuelle Daten können Sie verlieren?
Zum Beispiel kann ein kleines internes Wiki ein nächtliches mysqldump und eine einstündige Wiederherstellung tolerieren. Ein Produktionsbestellsystem benötigt möglicherweise physische Backups plus Binärlogs, damit Sie zu einer bestimmten Sekunde vor einem fehlerhaften DELETE wiederherstellen können.
Logische Backups mit mysqldump
Logische Backups exportieren Schema und Daten als SQL. Sie sind portabel und leicht zu überprüfen, aber bei großen Datenbanken können sie langsam zu erstellen und noch langsamer wiederherzustellen sein.
Eine Datenbank sichern:
mysqldump -u your_username -p your_database_name > backup_file.sql
Alle Datenbanken sichern:
mysqldump -u your_username -p --all-databases > all_databases_backup.sql
Bestimmte Tabellen sichern:
mysqldump -u your_username -p your_database_name table1 table2 > specific_tables_backup.sql
Fügen Sie Routinen, Ereignisse und Trigger hinzu, wenn Ihr Schema davon abhängt. Trigger sind in der typischen mysqldump-Verwendung standardmäßig enthalten, aber die explizite Angabe der Absicht in Ihrem Backup-Runbook hilft Prüfern, dies zu bemerken.
mysqldump -u your_username -p --routines --events --triggers your_database_name > database_with_programs.sql
In eine vorhandene Datenbank wiederherstellen:
mysql -u your_username -p your_database_name < backup_file.sql
Fügen Sie bei InnoDB-lastigen Workloads --single-transaction hinzu, damit der Dump einen konsistenten Snapshot ohne lange Tabellensperren liest:
mysqldump -u your_username -p --single-transaction --routines --events your_database_name | gzip > backup_file.sql.gz
Verwenden Sie --single-transaction nicht als einzigen Konsistenzschutz, wenn Sie auf nicht-transaktionale Tabellen wie MyISAM angewiesen sind. Diese Tabellen benötigen einen anderen Sperr- oder Snapshot-Plan.
Physische Backups für größere Datenbanken
Physische Backups kopieren MySQL-Datendateien, anstatt die Datenbank als SQL zu rekonstruieren. Sie sind in der Regel besser für große Datensätze geeignet, da die Wiederherstellungszeit näher am Zurückkopieren von Dateien und Anwenden von Wiederherstellungslogs liegt.
Häufige Optionen umfassen:
- Dateisystem- oder Cloud-Volume-Snapshots, die so koordiniert werden, dass MySQL-Daten crash-konsistent oder anwendungskonsistent sind.
- Percona XtraBackup, ein weit verbreitetes Open-Source-Tool für heiße physische Backups von MySQL-kompatiblen InnoDB-Daten.
- MySQL Enterprise Backup, Oracles kommerzielles Backup-Tool für MySQL Enterprise-Bereitstellungen.
Erstellen Sie ein vollständiges Backup mit XtraBackup:
xtrabackup --backup --target-dir=/path/to/backup/full --user=your_username --password=your_password
Bereiten Sie das Backup vor der Wiederherstellung vor:
xtrabackup --prepare --target-dir=/path/to/backup/full
Stellen Sie nach dem Stoppen von MySQL und dem Verschieben des alten Datenverzeichnisses wieder her:
systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.before-restore
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/path/to/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
Dieses Beispiel geht von einem Debian-ähnlichen Dienstnamen und Datenverzeichnis aus. Überprüfen Sie Ihre Paket-, Container-Image- oder verwaltete Datenbankdokumentation, bevor Sie Wiederherstellungsbefehle ausführen.
Binärlogs und Point-in-Time-Wiederherstellung
Backups geben an, von wo aus Sie wiederherstellen können. Binärlogs helfen Ihnen, Änderungen nach diesem Backup wiederzugeben, was Sie für die Point-in-Time-Wiederherstellung benötigen.
Aktivieren Sie die binäre Protokollierung auf selbstverwaltetem MySQL mit der entsprechenden log_bin-Einstellung für Ihre Version und Paketierung. Sichern Sie dann die Binärlogs getrennt vom Datenbankserver.
Bei der Wiederherstellung gehen Sie in der Regel wie folgt vor:
- Stellen Sie das letzte gute vollständige oder inkrementelle Backup wieder her.
- Verwenden Sie
mysqlbinlog, um Binärlogs bis zum Zielzeitpunkt oder zur Zielposition wiederzugeben. - Stoppen Sie vor der fehlerhaften Anweisung, wenn Sie sich von einem Bedienungsfehler erholen.
Die richtige Backup-Strategie wählen
Verwenden Sie eine einfache Entscheidungsregel:
- Kleine Datenbanken: Beginnen Sie mit automatisiertem
mysqldump, Komprimierung, externer Speicherung und regelmäßigen Wiederherstellungstests. - Mittlere Datenbanken: Fügen Sie Binärlog-Backups hinzu, um zu einem bestimmten Zeitpunkt wiederherstellen zu können.
- Große oder geschäftskritische Datenbanken: Verwenden Sie physische Backups, inkrementelle Backups (wo unterstützt), Binärlogs, Überwachung und eine dokumentierte Wiederherstellungsübung.
Wählen Sie nicht allein nach der Backup-Geschwindigkeit. Die Wiederherstellungsgeschwindigkeit ist während eines Vorfalls wichtiger.
Backup-Praktiken, die wirklich zählen
Automatisieren Sie den Backup-Job, testen Sie die Wiederherstellung jedoch manuell, bis der Prozess langweilig ist. Speichern Sie Backups extern, verschlüsseln Sie sensible Backups, überwachen Sie Job-Fehler und bewahren Sie die Aufbewahrungsfrist lang genug, um stille Korruption oder versehentliche Löschungen zu erkennen, die Tage später entdeckt werden.
Dokumentieren Sie auch die genaue Wiederherstellungsreihenfolge. Während eines echten Ausfalls sollte Ihr zukünftiges Ich nicht raten müssen, welches vollständige Backup, inkrementelle Backup und Binärlog-Bereich zusammengehören.
Fazit
Wählen Sie die Backup-Methode, die Ihrem Wiederherstellungsziel entspricht. mysqldump ist für kleine Datenbanken und portable Wiederherstellungen geeignet. Physische Backups passen zu größeren Systemen. Binärlogs schließen die Lücke, wenn Sie eine Point-in-Time-Wiederherstellung benötigen. Was auch immer Sie wählen, ein Backup zählt erst, wenn Sie es erfolgreich in einer Testumgebung wiederhergestellt haben.