MySQL bietet von Haus aus einige Lösungsansätze um die Datensicherheit zu gewährleisten. Eine davon ist die unidirektionale, asynchrone Replikation (seit v3.23.15) einer Master Datenbank auf einen oder mehreren Slave Datenbanken. Im folgenden beschreibe ich Schritt für Schritt die Einrichtung solch eines DB-Verbunds.

Die Replikation ermöglicht eine exakte Kopie der Master Datenbank als redundante Sicherung. Man sollte sich bewusst darüber sein, dass alle SQL-Befehle die beim Master abgesetzt werden 1 zu 1 auf dem Slave übernommen werden.
Vor einer fehlerhaften Anwendung, die bsp. Datensätze korrumpiert, ist die Replikation nicht gefeit. Nichtdestotrotz eröffnet die Replikation Wege in Bezug Ausfallsicherheit oder Lastverteilung.
Ich empfehle bei der Replikation gleiche MySQL Versionen von Master und Slave zu benutzen. Unter http://mysql2.mirrors-r-us.net/doc/refman/5.1/de/replication-compatibility.html kann man Details zur Kompatiblität erfahren.

1. Schritt – Master Datenbank vorbereiten

Zuerst muss ein Benutzer auf der Master-DB mit Replikations-Berechtigung erzeugt werden. Dieser Benutzer-Account dient später zur Replizierung der Daten. Auf der Kommadozeile in MySQL sähe das folgendermaßen aus:

mysql> GRANT REPLICATION SLAVE ON *.* TO slave@’%.ihredomain.de’ IDENTIFIED BY ‘ihrPasswort’;

Wenn man später mit LOAD DATA FROM MASTER agieren möchte dann benötigt dieser Account ein paar Rechte mehr (SELECT, RELOAD, SUPER, REPLICATION SLAVE).
Als nächstes muss die my.cnf des Master editiert werden

[mysqld]
log-bin
server-id=1

Hiermit aktivieren wir das binäre loggen des Masters, welches notwenig für die Replikation ist. Des weiteren geben wir dem Master eine eindeutige ID.

2. Schritt – Master Datenbank sichern

Diesen Schritt kann man sich auch sparen, wenn der Master keine oder nur wenige Daten zu diesem Zeitpunkt führt. Dann setzt man einfach nach Schritt 4 folgendes Kommando auf dem MySQL-Prompt ab:

mysql> LOAD DATA FROM MASTER;

Wie bereits erwähnt benötigt der Replikations-Account hierfür weitere Rechte (RELOAD,SUPER). Mit dem Kommando holt sich der Slave alle Daten vom Master, aber Vorsicht er blockiert hiermit den Master über den Zeitraum des Ladeprozesses, bei vielen Daten ist dieses Vorgehen nicht zu empfehlen.

Nun müssen wir den IST-Zustand der Master-DB-Daten erfassen und dem Slave später als Ausgangspunkt zur Verfügung stellen. Als erste Handlung hierbei, muss man die Master-Tabellen sperren, das erfolgt am MySQL-Prompt mit:

mysql> FLUSH TABLES WITH READ LOCK;

Jetzt erfolgt ein Full-Backup der Master DB aus der Kommandozeile mit (bsp. in /var/lib/mysql/):

tar -cvf /tmp/master-backup.tar

Zur Sicherheit legt man eine Kopie von diesem Backup zurück, um eventuell später weitere Slaves mit diesem Datenbestand zu initialisieren. Als nächstes benötigen wir noch die Binary Log Position um den Slave später den Anfangspunkt der Replizierung mitzuteilen. Auf dem MySQL-Prompt geschieht das mit:

mysql> SHOW MASTER STATUS;

Diesen Wert notieren wir. Nun haben wir alle nötigen Daten des Masters und können dessen Tabellen entsperren:

mysql> UNLOCK TABLES;

3. Schritt – Ausgangs-Backup in Slave einspielen

Im Slave Datenverzeichnis entpacken wir das eben angelegte Backup mit

tar -xvf master-backup.tar

Dieses Backup dient dem Slave als Ausgangspunkt für das spätere unidirektionale, asynchrone replizieren.

4. Schritt – Slave Datenbank vorbereiten

Der Slave benötigt nun auch eine eindeutige ID, diese tragen wir in die Slave my.cnf folgendes ein:

[mysqld]
server-id=2

Jetzt füttern wir den Slave mit den notwenigen Daten des Masters auf dem MySQL-Prompt:

mysql> CHANGE MASTER TO
-> MASTER_HOST=MASTER-IP,
-> MASTER_USER=Name des Replikation Account,
-> MASTER_PASSWORD=Passwort des Replikations-Accounts,
-> MASTER_LOG_FILE=Name des Binary-Logs aus dem Snapshot,
-> MASTER_LOG_POS=Binary Log Position;

Anschliessend muss der Slave nur noch seinen Dienst aufnehmen mit:

mysql> START SLAVE;

Nach absetzen des Befehls nimmt der Slave sofort Kontakt mit dem Master auf und orientiert sich am Binary Log um die Replizierung durchzuführen.

Voila!

Mit

mysql> SHOW MASTER STATUS;

und

mysql> SHOW SLAVE STATUS;

kann man nun Master und Slave kontrollieren. Hierbei ist darauf zu achten, dass auf dem Slave die Stati Slave_IO_Running und Slave_SQL_Running auf YES stehen.
Unter http://mysql2.mirrors-r-us.net/doc/refman/5.1/de/replication.html findet man weiterführende Informationen und Hilfestellungen. Aus meiner Erfahrung heraus sind bei Master-Slave Gefügen auftretenden Probleme oft bei der Berechtigung des Replikations-Accounts und/oder des Verbindungsaufbaues zu suchen.

Hinweise

Man sollte sicherstellen, dass der Master Verbindungen von ausserhalb zulässt, sofern der Replikant nicht im selben Netz (localhost) integriert ist, aber Vorsicht dies ist ein Sicherheitsmanko. Auch diese Einstellung nimmt man in der my.cnf vor, in dem man die Zeile

#skip-networking

mit # auskommentiert. Taucht diese Zeile

#bind-address = 127.0.0.1

in der my.cnf auf, muss auch diese auskommentiert werden. Sie bedeutet nichts anderes als das nur von localhost verbunden werden darf.

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• High Performance MySQL. Optimierung, Datensicherung, Replikation & Lastverteilung von Jeremy D. Zawodny und Derek J. Balling
• Das offizielle MySQL 5-Handbuch von MySQL MySQL AB
• MySQL 5. Einführung, Programmierung, Referenz (Open Source Library) von Michael Kofler
• MySQL 5. Für Professionals von Axel Bornträger