magazin-tipps-tricks
+2

MySQL Backups

OS und Programm:

– Linux bzw. unixoid

– MySQL, MariaDB u.ä.

Problem:

MySQL ist heutzutage eines der wohl am meisten verbreiteten relationalen Datenbankverwaltungssysteme und wer kennt es nicht, irgendwas crashed immer mal (egal warum ^^). Sei es nun der Rechner, ein belieger Daemon oder halt mal MySQL. Mit diesem kleinem HowTo wollen wir euch zeigen wie einfach es ist, zwar nicht den Crash oder Dummheit zu vermeiden, aber zumindest den Datenverlust bzw. Inkonsistenzen möglichst gering zu halten.

Lösung:

Jaja, dass es sich bei der Lösung um regelmäßige Backups handeln könnte, wird nicht allzu schwer zu erraten sein. Im Folgenden wird deshalb EIN mögliches Vorgehen anhand von inkrementellen Backups kurz skizziert. Hierbei wird allerdings nicht auf einen Sicherungsplan oder gar eine Strategie eingegangen, dies würde ein wenig länger dauern.

  • Zuerst solltet ihr sicherstellen, dass euer Server mit aktiviertem Binlog gestartet wurde. Dazu sollte in der entsprechenden Konfigurationsdatei die folgende Zeile vorhanden und NICHT auskommentiert sein:
    lumpi@wurscht:~$ vim /etc/mysql/my.cnf
    ...
    log_bin = /var/log/mysql/mysql-binlog
    ...

    Der Pfad/Dateiname kann hierbei euren Wünschen entsprechend angepasst sein und es wäre sicherlich nicht schlecht, wenn die Logs auf einem eigenen Laufwerk/Partition liegen würden. Das könnte u.a. bei einem Crash der Platte nützlich sein.

  • Nun erstellt ihr einen vollständigen Dump, ergo ein Vollbackup. Hierbei ist darauf zu achten, das grundsätzlich ein neues Binlog genutzt wird und möglichst keine administrativen Änderungen mehr vorgenommen werden (gerade bei Engines ohne Transaktionssicherheit wie MyISAM wichtig). Mit dem folgenden Befehl werden alle Datenbanken unter Synchronisation der Logs (–all-databases, –flush-logs) in die gewünschte Backupdatei geschrieben. Dabei wird via –master-data=2 die Position und der Dateiname des Binlogs als Kommentar in die Ausgabedatei geschrieben (2 ist Default und kann auch weggelassen werden). –single-transaction wirkt hierbei nur bei Engines mit Transaktionssicherheit.
    lumpi@wurscht:~$ mysqldump --single-transaction --flush-logs --master-data=2 --all-databases > full_dump.sql
  • Um inkrementelle Backups zu erstellen muss der Server ein neues Binlog nutzen. Dazu kann man folgenden Befehl nutzen:
    lumpi@wurscht:~$ mysqladmin flush-logs

    Das alte Binlog kann dann als inkrementelles Backup gesichert werden.

  • Was aber nun tun, wenn der Ernstfall durch Dummheit oder Crash oder was weiß ich, doch mal eingetreten ist? Wie spielt man ein inkrementelles Backup zurück?
  • Ganz einfach. Man nehme das letzte Vollbackup und alle folgenden inkrementellen Backups und importiere nun den vollständigen Dump in eine leere DB und anschließend alle Binlogs.
    lumpi@wurscht:~$ mysql < full-full_dump.sql
    lumpi@wurscht:~$ mysqlbinlog mysql-binlog.1 mysql-binlog.2 mysql-binlog.3 mysql-binlog.4| mysql

    Am Besten werden alle nötigen Binlogs auf einmal eingespielt, da es sonst zu Problemen führen könnte, bspw. falls für bestimmte Strukturen mehrere Binlogs verwendet wurden.

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *