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“.
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.)
Wenn mysqld läuft, beenden Sie es und
starten Sie es dann mit der Option
--log-bin[=
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.
file_name
]
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.
Stellen Sie das ursprüngliche mysqldump-Backup oder das binäre Backup wieder her.
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 '
. Um Datensatzdubletten zu verhindern, muss die
Tabelle einen file_name
' REPLACE
...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:
Führen Sie im Clientprogramm FLUSH TABLES WITH
READ LOCK
aus.
Führen Sie unter einer anderen Shell mount vxfs
snapshot
aus.
Führen Sie nun wiederum auf dem ersten Client
UNLOCK TABLES
aus.
Kopieren Sie die Dateien aus dem Schnappschuss.
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.