Skip navigation links
5.10.2 Beispielhaftes Vorgehen zur Datensicherung und Wiederherstellung »
Section Navigation      [Toggle]

5.10.1. Datenbank-Datensicherungen

Da MySQL-Tabellen als Dateien gespeichert werden, ist die Durchführung einer Datensicherung recht einfach. Um ein konsistentes Backup zu erhalten, führen Sie für die gewünschten Tabellen nacheinander die Anweisungen LOCK TABLES und FLUSH TABLES aus. Siehe auch Abschnitt 13.4.5, „LOCK TABLES und UNLOCK TABLES“, und Abschnitt 13.5.5.2, „FLUSH“. Sie benötigen lediglich eine Lesesperre, d. h. andere Clients können die Tabellen weiterhin abfragen, während Sie eine Kopie der Dateien im Datenbankverzeichnis erstellen. Die Anweisung FLUSH TABLES ist erforderlich, um sicherzustellen, dass alle aktiven Indexseiten auf Festplatte geschrieben werden, bevor Sie die Sicherung starten.

Um eine Tabelle auf SQL-Ebene zu sichern, können Sie SELECT INTO ... OUTFILE verwenden. Bei dieser Anweisung darf die Ausgabedatei nicht bereits vorhanden sein, da das Überschreiben vorhandener Dateien ein Sicherheitsrisiko darstellen würde. Siehe auch Abschnitt 13.2.7, „SELECT“.

Eine weitere Methode zur Sicherung einer Datenbank besteht in der Verwendung des Programms mysqldump oder des Skripts mysqlhotcopy. Siehe auch Abschnitt 8.10, „mysqldump — Programm zur Datensicherung“, und Abschnitt 8.11, „mysqlhotcopy — Backup-Programm für Datenbanken“.

  1. Erstellen Sie eine vollständige Sicherung Ihrer Datenbank: 

    shell> mysqldump --tab=/path/to/some/dir --opt db_name

    Oder: 

    shell> mysqlhotcopy db_name /path/to/some/dir

    Sie können auch eine binäre Sicherung erstellen, indem Sie einfach alle Tabellendateien (*.frm, *.MYD und *.MYI) kopieren, während der Server keine Aktualisierungen vornimmt. Das Skript mysqlhotcopy verwendet diese Methode. (Beachten Sie aber, dass diese Methoden nicht funktionieren, wenn Ihre Datenbank InnoDB-Tabellen enthält. InnoDB speichert die Tabelleninhalte nicht in Datenbankverzeichnissen, und mysqlhotcopy funktioniert nur bei MyISAM-Tabellen.)

  2. Wenn mysqld läuft, beenden Sie es und starten Sie es dann mit der Option --log-bin[=file_name] neu. Siehe auch Abschnitt 5.12.3, „Die binäre Update-Logdatei“. Die Binärlogdateien vermitteln Ihnen die Informationen, die Sie zur Replikation von Änderungen an der Datenbank benötigen, die nach dem Punkt, an dem Sie mysqldump ausgeführt haben, durchgeführt wurden.

Bei InnoDB-Tabellen können Sie ein Onlinebackup durchführen, bei dem die Tabellen nicht gesperrt werden; siehe auch Abschnitt 8.10, „mysqldump — Programm zur Datensicherung“.

MySQL unterstützt inkrementelle Backups: Zu diesem Zweck müssen Sie den Server mit der Option --log-bin starten (Abschnitt 5.12.3, „Die binäre Update-Logdatei“). Sobald Sie ein inkrementelles Backup erstellen wollen (d. h. eine Sicherung, die alle seit dem letzten vollständigen oder inkrementellen Backup vorgenommenen Änderungen enthält), dann sollten Sie das Binärlog mit FLUSH LOGS rotieren. Danach müssen Sie alle Binärlogs, die aus dem Zeitraum zwischen dem letzten vollständigen oder inkrementellen Backup und dem vorletzten erstellten Log stammen, an die Sicherungsposition kopieren. Diese Binärlogs bilden die inkrementelle Sicherung; wenn eine Wiederherstellung erforderlich ist, wenden Sie sie wie weiter unten erläutert an. Wenn Sie beim nächsten Mal eine vollständige Sicherung durchführen, sollten Sie das Binärlog ebenfalls mit FLUSH LOGS, mysqldump --flush-logs oder mysqlhotcopy --flushlog rotieren. Siehe auch Abschnitt 8.10, „mysqldump — Programm zur Datensicherung“, und Abschnitt 8.11, „mysqlhotcopy — Backup-Programm für Datenbanken“.

Wenn Ihr MySQL-Server ein Slave-Replikationsserver ist, dann sollten Sie unabhängig von der gewählten Sicherungsmethode auch die Dateien master.info und relay-log.info sichern, wenn Sie ein Backup der Daten auf Ihrem Slave durchführen. Diese Dateien werden immer benötigt, um die Replikation nach Wiederherstellung der Daten auf dem Slave fortzusetzen. Wenn Ihr Slave Gegenstand der Replikation von LOAD DATA INFILE-Befehlen ist, sollten Sie auch alle SQL_LOAD-*-Dateien sichern, die ggf. in dem mit der Option --slave-load-tmpdir angegebenen Verzeichnis vorhanden sind. (Sofern die Option nicht angegeben wurde, ist die Position standardmäßig der Wert der Variable tmpdir.) Der Slave benötigt diese Dateien, um die Replikation unterbrochener LOAD DATA INFILE-Operationen fortzusetzen.

Wenn Sie MyISAM-Tabellen wiederherstellen müssen, probieren Sie dies zunächst mit REPAIR TABLE oder myisamchk -r. Dies sollte in 99,9 Prozent aller Fälle funktionieren. Schlägt der Befehl myisamchk fehl, dann probieren Sie die nachfolgend beschriebene Vorgehensweise aus. Beachten Sie, dass dies nur funktioniert, wenn Sie durch Starten von MySQL mit der Option --log-bin das binäre Loggen aktiviert haben.

  1. Stellen Sie das ursprüngliche mysqldump-Backup oder das binäre Backup wieder her.

  2. Führen Sie den folgenden Befehl aus, um die Aktualisierungen in den Binärlogs erneut auszuführen: 

    shell> mysqlbinlog binlog.[0-9]* | mysql

    In manchen Fällen wollen Sie unter Umständen nur bestimmte Binärlogs in bestimmten Verzeichnissen erneut ausführen (wobei Sie in der Regel alle Binärlogs ab dem Datum der wiedergestellten Sicherung wiederherstellen sollten – möglicherweise abgesehen von einigen falschen Anweisungen). Weitere Informationen zum Hilfsprogramm mysqlbinlog und seiner Verwendung finden Sie in Abschnitt 8.8, „mysqlbinlog — Hilfsprogramm für die Verarbeitung binärer Logdateien“.

Sie können auch selektive Sicherungen einzelner Dateien vornehmen:

  • Um einen Speicherauszug einer Tabelle zu erstellen, verwenden Sie SELECT * INTO OUTFILE 'file_name' FROM tbl_name.

  • Um die Tabelle wieder zu laden, verwenden Sie LOAD DATA INFILE 'file_name' REPLACE .... Um Datensatzdubletten zu verhindern, muss die Tabelle einen PRIMARY KEY- oder einen UNIQUE-Index aufweisen. Das Schlüsselwort REPLACE sorgt dafür, dass alte Datensätze durch neue ersetzt werden, wenn ein eindeutiger Schlüsselwert in einem neuen Datensatz dem eines alten Datensatzes entspricht.

Wenn Sie bei der Durchführung von Sicherungen Probleme mit der Serverleistung haben, besteht eine mögliche Abhilfe darin, die Replikation zu konfigurieren und Backups auf dem Slave statt auf dem Master durchzuführen. Siehe auch Abschnitt 6.1, „Einführung in die Replikation“.

Wenn Sie ein Veritas-Dateisystem verwenden, können Sie das Backup wie folgt erstellen:

  1. Führen Sie im Clientprogramm FLUSH TABLES WITH READ LOCK aus.

  2. Führen Sie unter einer anderen Shell mount vxfs snapshot aus.

  3. Führen Sie nun wiederum auf dem ersten Client UNLOCK TABLES aus.

  4. Kopieren Sie die Dateien aus dem Schnappschuss.

  5. Trennen Sie den Schnappschuss ab.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.