Dieser Abschnitt beschreibt kurz, wie man die vollständige Replikation eines MySQL Servers konfiguriert. Es wird angenommen, dass Sie alle Datenbanken auf dem Master replizieren wollen und die Replikation zuvor noch nicht konfiguriert haben. Sie müssen Ihren Master-Server kurz herunterfahren, um die beschriebenen Schritte vollständig durchführen zu können.
Beschrieben wird der Vorgang für die Konfiguration eines einzelnen Slaves; mehrere Slaves können Sie konfigurieren, indem Sie die entsprechenden Schritte wiederholen.
Zwar ist diese Vorgehensweise die direkteste zur Konfiguration eines Slaves, sie ist aber nicht die einzige. Wenn Sie beispielsweise eine Momentaufnahme der Daten auf dem Master haben und auf diesem bereits die Serverkennung eingestellt und das binäre Loggen aktiviert ist, dann können Sie einen Slave konfigurieren, ohne den Master herunterzufahren oder auch nur Aktualisierungen zu unterbinden. Weitere Informationen finden Sie unter Abschnitt 6.11, „Replikation: häufig gestellte Fragen“.
Wenn Sie eine MySQL-Replikationskonfiguration administrieren wollen, sollten Sie dieses Kapitel vollständig lesen und alle Anweisungen ausprobieren, die in Abschnitt 13.6.1, „SQL-Anweisungen für die Steuerung von Master-Servern“, und Abschnitt 13.6.2, „SQL-Anweisungen für die Steuerung von Slave-Servern“, beschrieben sind. Ferner sollten Sie sich mit den Replikationsstartoptionen vertraut machen, die in Abschnitt 6.9, „Replikationsoptionen in my.cnf“, erläutert werden.
Hinweis: Diese Methode und einige
der replikationsspezifischen SQL-Anweisungen, die in späteren
Abschnitten beschrieben werden, erfordern die Berechtigung
SUPER
.
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:
Gewähren Sie dem Konto die globalen Berechtigungen
SUPER
und RELOAD
.
Gewähren Sie die Berechtigung SELECT
für alle Tabellen, die Sie laden wollen. Alle
Master-Tabellen, für die das Konto keine
SELECT
-Berechtigung hat, werden von
LOAD DATA FROM MASTER
ignoriert.
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=
enthalten, wobei master_id
master_id
ein
positiver Integer zwischen 1 und
232 – 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 232 –
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:
MASTER_HOST |
60 |
MASTER_USER |
16 |
MASTER_PASSWORD |
32 |
MASTER_LOG_FILE |
255 |
Starten Sie die Slave-Threads:
mysql> START SLAVE;
Nachdem Sie diesen Vorgang durchgeführt haben, sollte der Slave eine Verbindung mit dem Master herstellen und alle Updates nachholen, die seit Erstellung der Momentaufnahme erstellt wurden.
Wenn Sie es versäumt haben, die Option
server-id
für den Master einzustellen, dann
können Slaves keine Verbindung herstellen.
Wenn Sie es versäumt haben, die Option
server-id
für den Slave einzustellen, dann
erhalten Sie im Fehlerlog des Slaves die folgende Meldung:
Warning: You should set server-id to a non-0 value if master_host is set; we will force server id to 2, but this MySQL server will not act as a slave.
Ferner werden Sie Fehlermeldungen im Fehlerlog des Slaves vorfinden, wenn eine Replikation aus irgendeinem anderen Grund nicht möglich ist.
Sobald ein Slave mit der Replikation begonnen hat, finden Sie in
seinem Datenverzeichnis zwei Dateien namens
master.info
und
relay-log.info
. Der Slave verwendet diese
beiden Dateien, um zu vermerken, welcher Anteil des
Master-Binärlogs bereits verarbeitet wurde. Sie dürfen diese
Dateien keinesfalls entfernen oder
bearbeiten, sofern Sie nicht genau wissen, was Sie tun und welche
Auswirkungen dies haben kann. Und auch in diesem Fall sollten Sie
besser die CHANGE MASTER TO
-Anweisung
verwenden, um die Replikationsparameter zu ändern. Der Slave
aktualisiert die Statusdateien automatisch entsprechend den
Werten, die in dieser Anweisung angegeben sind.
Hinweis: Der Inhalt von
master.info
setzt einige der Serveroptionen,
die auf der Befehlszeile oder in der Datei
my.cnf
angegeben sind, außer Kraft. Weitere
Informationen finden Sie in
Abschnitt 6.9, „Replikationsoptionen in my.cnf“.
Sobald Sie über eine Momentaufnahme des Masters verfügen, können Sie diese zur Konfiguration weiterer Slaves verwenden. Folgen Sie dabei einfach der oben beschriebenen Anleitung. Sie müssen also keine neue Momentaufnahme erstellen, sondern können dieselbe auch für jeden weiteren Slave verwenden.
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.