Vergewissern Sie sich, dass die auf dem Master und dem Slave installierten MySQL-Versionen kompatibel im Sinne der in Abschnitt 6.6, „Replikation: Kompatibilität zwischen MySQL-Versionen“, aufgeführten Tabelle sind. Im Idealfall sollten Sie die jeweils aktuellste MySQL-Version sowohl auf dem Master als auch auf dem Slave verwenden.

Wenn Sie auf ein Problem stoßen, melden Sie dieses bitte erst als Bug, nachdem Sie sich vergewissert haben, dass es auch im aktuellen MySQL-Release vorhanden ist.

Konfigurieren Sie ein Konto auf dem Master-Server, über das der Slave eine Verbindung herstellen kann. Dieses Konto benötigt die Berechtigung REPLICATION SLAVE. Wenn das Konto ausschließlich zur Replikation verwendet wird (was wir empfehlen), dann brauchen Sie keine weiteren Berechtigungen zu gewähren.

Nehmen wir nun an, dass Ihre Domäne mydomain.com heißt und dass Sie ein Konto mit dem Benutzernamen repl erstellen wollen, das Slave-Server unter Angabe des Passworts slavepass von einem beliebigen Host in Ihrer Domäne aus für den Zugriff auf den Master verwenden kann. Dieses Konto erstellen Sie mit folgender GRANT-Anweisung:

mysql> GRANT REPLICATION SLAVE ON *.*
    -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';

Beabsichtigen Sie, die Anweisungen LOAD TABLE FROM MASTER oder LOAD DATA FROM MASTER auf dem Slave-Host zu verwenden, dann müssen Sie diesem Konto weitere Berechtigungen gewähren:

Weitere Informationen zur Konfiguration von Benutzerkonten und Berechtigungen finden Sie in Abschnitt 5.9, „MySQL-Benutzerkontenverwaltung“.

Synchronisieren Sie alle Tabellen und unterbinden Sie Schreibanweisungen, indem Sie eine FLUSH TABLES WITH READ LOCK-Anweisung ausführen:

mysql> FLUSH TABLES WITH READ LOCK;

Beachten Sie, dass FLUSH TABLES WITH READ LOCK bei InnoDB-Tabellen auch COMMIT-Operationen sperrt. Wenn Sie eine globale Lesesperre erwirkt haben, können Sie eine Dateisystem-Momentaufnahme Ihrer InnoDB-Tabellen erstellen. Intern (d. h. innerhalb der InnoDB-Speicher-Engine) ist diese Momentaufnahme nicht konsistent, weil die InnoDB-Caches nicht synchronisiert wurden, aber dies ist nicht weiter problematisch, weil InnoDB dieses Problem beim Start beseitigt und ein konsistentes Ergebnis abliefert. Das bedeutet, dass bei InnoDB die Wiederherstellung von Daten nach einem Absturz verlustfrei möglich ist, wenn der Neustart auf der Basis dieser Momentaufnahme erfolgt. Allerdings gibt es keine Möglichkeit, den MySQL Server zu beenden und gleichzeitig eine konsistente Momentaufnahme Ihrer InnoDB-Tabellen zu gewährleisten.

Lassen Sie den Client laufen, von dem aus Sie die FLUSH TABLES-Anweisung absetzen, damit die Lesesperre aktiv bleibt. (Wenn Sie den Client beenden, wird die Sperre aufgehoben.) Erstellen Sie nun eine Momentaufnahme der Daten auf Ihrem Master-Server.

Die einfachste Möglichkeit zur Erstellung einer Momentaufnahme ist die Verwendung eines Archivierungsprogramms: Hiermit erstellen Sie eine binäre Sicherung der Datenbanken im Datenverzeichnis Ihres Master-Servers. Sie können beispielsweise tar unter Unix oder PowerArchiver, WinRAR, WinZip oder eine ähnliche Software unter Windows verwenden. Um mit tar ein Archiv zu erstellen, das alle Datenbanken enthält, wechseln Sie in das Datenverzeichnis des Master-Servers und führen dann folgenden Befehl aus:

shell> tar -cvf /tmp/mysql-snapshot.tar .

Wollen Sie, dass das Archiv nur eine Datenbank namens this_db enthält, dann verwenden Sie stattdessen folgenden Befehl:

shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db

Danach kopieren Sie die Archivdatei in das Verzeichnis /tmp auf dem Slave-Serverhost. Auf diesem System wechseln Sie nun in das Datenverzeichnis des Slaves und entpacken die Archivdatei mithilfe des folgenden Befehls:

shell> tar -xvf /tmp/mysql-snapshot.tar

Wenn auf dem Slave-Server andere Benutzerkonten als auf dem Master vorhanden sind, sollten Sie die Datenbank mysql unter Umständen nicht replizieren. In diesem Fall sollten Sie sie aus dem Archiv ausschließen. Ferner sollten Sie weder Logdateien noch die Dateien master.info oder relay-log.info in das Archiv einfügen.

Während die mit FLUSH TABLES WITH READ LOCK erwirkte Lesesperre gültig ist, lesen Sie den Namen des aktuellen Binärlogs und den Versatz auf dem Master aus:

mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73       | test         | manual,mysql     |
+---------------+----------+--------------+------------------+

Die Spalte File zeigt den Namen der Logdatei an, Position den Versatz innerhalb der Datei. In diesem Beispiel heißt die Binärlogdatei mysql-bin.003, der Versatz ist 73. Notieren Sie diese Werte. Sie benötigen sie später beim Konfigurieren des Slaves. Die Werte stellen die Replikationskoordinaten dar, bei denen der Slave die Verarbeitung neuer Updates vom Master startet.

Wenn der Master zuvor ohne aktiviertes Binärloggen ausgeführt wurde, sind die von SHOW MASTER STATUS oder mysqldump --master-data angezeigten Werte für Lognamen und Position leer. In diesem Fall lauten die Werte, die Sie später als Logdateinamen und Position auf dem Slave angeben müssen, '' (Leer-String) und 4.

Nachdem Sie die Momentaufnahme erstellt und Lognamen und Versatz aufgezeichnet haben, können Sie die Schreibaktivitäten auf dem Master neu starten:

mysql> UNLOCK TABLES;

Wenn Sie InnoDB-Tabellen einsetzen, sollten Sie im Idealfall das Tool InnoDB Hot Backup verwenden, welches ohne Sperre auf dem Master-Server eine konsistente Momentaufnahme erstellt und Lognamen und Versatz passend für die Momentaufnahme speichert, sodass die Angaben später auf dem Slave benutzt werden können. Hot Backup ist ein kommerzielles (d. h. nicht kostenloses) Zusatztool, das nicht Bestandteil der MySQL-Standarddistribution ist. Weitere Informationen finden Sie auf der Homepage von InnoDB Hot Backup unter http://www.innodb.com/manual.php.

Wenn Sie Hot Backup nicht einsetzen, besteht die schnellste Methode zur Erstellung einer binären Momentaufnahme der InnoDB-Tabellen darin, den Master-Server herunterzufahren und die Datendateien, Logdateien und Tabellenformatdateien (.frm) von InnoDB zu kopieren. Um den aktuellen Logdateinamen und den Versatz aufzuzeichnen, sollten Sie folgende Anweisungen absetzen, bevor Sie den Server herunterfahren:

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

Dann notieren Sie Lognamen und Versatz aus der Ausgabe von SHOW MASTER STATUS wie oben beschrieben. Danach fahren Sie den Server herunter, ohne die Tabellen zu entsperren; hierdurch ist sicherstellt, dass der Server mit einem Status beendet wird, der den Angaben zu Logdatei und Versatz entspricht:

shell> mysqladmin -u root shutdown

Eine Alternative, die sowohl bei MyISAM- als auch bei InnoDB-Tabellen funktioniert, besteht darin, einen SQL-Speicherauszug des Masters anstatt – wie oben beschrieben – einer binären Kopie zu erstellen. Hierzu führen Sie mysqldump --master-data auf dem Master aus und laden die SQL-Speicherauszugsdatei später in Ihren Slave. Allerdings ist die Erstellung einer binären Kopie schneller.

Vergewissern Sie sich, dass der Abschnitt [mysqld] der Datei my.cnf auf dem Master-Host die Option log-bin enthält. Der Abschnitt sollte ferner eine Option server-id=master_id enthalten, wobei master_id ein positiver Integer zwischen 1 und 2³² – 1 sein muss. Zum Beispiel:

[mysqld]
log-bin=mysql-bin
server-id=1

Wenn diese Optionen nicht vorhanden sind, fügen Sie sie hinzu und starten den Server neu. Der Server kann erst als Replikationsmaster agieren, wenn das binäre Loggen aktiviert ist.

Hinweis: Um die größtmögliche Dauerhaftigkeit und Konsistenz in einer Replikationskonfiguration für InnoDB mit Transaktionen zu erzielen, sollten Sie innodb_flush_log_at_trx_commit=1 und sync_binlog=1 in der Datei my.cnf auf dem Master angeben.

Beenden Sie den Server, der als Slave vorgesehen ist, und fügen Sie in seiner Datei my.cnf die folgenden Zeilen hinzu:

[mysqld]
server-id=slave_id

Der Wert slave_id muss wie master_id auch ein positiver Integer zwischen 1 und 2³² – 1 sein. Ferner muss sich die Kennung des Slaves von der des Masters unterscheiden. Zum Beispiel:

[mysqld]
server-id=2

Wenn Sie mehrere Slaves konfigurieren, muss jeder einen eindeutigen server-id-Wert haben, der sich von dem des Masters und von denen aller anderen Slaves unterscheidet. Betrachten Sie server-id-Werte als etwas Ähnliches wie IP-Adressen: Diese Kennungen identifizieren jede Serverinstanz in der Gruppe der Replikationspartner eindeutig.

Wenn Sie keinen server-id-Wert angeben, wird er auf 1 gesetzt, sofern Sie master-host nicht definiert haben; andernfalls wird der Wert auf 2 gesetzt. Beachten Sie, dass, wenn Sie server-id weglassen, ein Master Verbindungen aller Slaves abweist und auch ein Slave sich weigert, eine Verbindung mit einem Master herzustellen. Auf diese Weise ist das Übergehen von server-id nur für ein Backup mit einem Binärlog geeignet.

Wenn Sie eine binäre Sicherung der Daten auf dem Master-Server erstellt haben, kopieren Sie sie in das Datenverzeichnis des Slaves, bevor Sie diesen starten. Stellen Sie sicher, dass die Berechtigungen für Dateien und Verzeichnisse korrekt sind. Das Systemkonto, über das Sie den Slave-Server ausführen, muss die Dateien wie beim Master auch lesen und schreiben können.

Wenn Sie ein Backup mit mysqldump erstellen, starten Sie den Slave zuerst. Die Speicherauszugsdatei wird in einem späteren Schritt geladen.

Starten Sie den Slave-Server. Erfolgte bereits früher eine Replikation, dann starten Sie den Slave mit der Option --skip-slave-start, damit er nicht sofort versucht, eine Verbindung mit dem Master herzustellen. Sie sollten den Slave-Server außerdem mit der Option --log-warnings starten, um im Falle von Problemen (z. B. Netzwerk- oder Verbindungsproblemen) mehr Meldungen im Fehlerlog zu erhalten. Die Option ist standardmäßig aktiviert, aber abgebrochene Verbindungen werden nicht im Fehlerlog vermerkt, sofern der Optionswert nicht größer als 1 ist.

Wenn Sie mit mysqldump ein Backup der Daten auf dem Master-Server erstellt haben, laden Sie die Speicherauszugsdatei in den Slave-Server:

shell> mysql -u root -p < dump_file.sql

Führen Sie die folgende Anweisung auf dem Slave aus und ersetzen Sie dabei die Optionswerte durch die für Ihr System geeigneten Werte:

mysql> CHANGE MASTER TO
    -> MASTER_HOST='master_host_name',
    -> MASTER_USER='replication_user_name',
    -> MASTER_PASSWORD='replication_password',
    -> MASTER_LOG_FILE='recorded_log_file_name',
    -> MASTER_LOG_POS=recorded_log_position;

Die folgende Tabelle zeigt die maximal zulässige Länge bei Optionen, die String-Werte enthalten:

Starten Sie die Slave-Threads:

mysql> START SLAVE;