--master-host

--master-user

--master-password

--master-port

--master-connect-retry

--master-ssl

--master-ssl-ca

--master-ssl-capath

--master-ssl-cert

--master-ssl-cipher

--master-ssl-key

--log-slave-updates

Normalerweise vermerkt ein Slave Updates, die er von einem Master-Server erhalten hat, nicht in seinem eigenen Binärlog. Diese Option weist den Slave jedoch an, Updates, die von seinem SQL-Thread ausgeführt wurden, in sein eigenes Binärlog zu schreiben. Damit diese Option Wirkung zeigt, muss der Slave auch mit der Option --log-bin gestartet werden, um das binäre Loggen zu aktivieren. --log-slave-updates wird verwendet, wenn Sie Replikationsserver seriell verketten. Nehmen wir an, Sie wollen die Replikationsserver wie folgt anordnen:

A -> B -> C

Hier dient A als Master von Slave B, und B agiert seinerseits als Master von Slave C. Damit dies funktioniert, muss B gleichermaßen Master und Slave sein. Sie müssen A und B mit der Option --log-bin starten, um das binäre Loggen zu aktivieren. Ferner muss B auch mit der Option --log-slave-updates gestartet werden, damit Änderungen, die von A empfangen wurden, von B auch im eigenen Binärlog vermerkt werden.

--log-warnings

Mit dieser Option schreibt ein Server mehr Meldungen zu seinen Aktionen in das Fehlerlog. In Hinsicht auf die Replikation erzeugt der Server Warnungen, wenn er nach einem Netzwerk- oder Verbindungsausfall eine Neuverbindung herstellen konnte, und gibt auch an, wann die einzelnen Slave-Threads gestartet wurden. Die Option ist standardmäßig aktiviert. Sie können sie mithilfe von --skip-log-warnings deaktivieren. Unterbrochene Verbindungen werden nicht in das Fehlerlog protokolliert, sofern der Wert größer als 1 ist.

--master-connect-retry=seconds

Die Anzahl von Sekunden, für die der Slave-Thread im Falle eines Ausfalls der Verbindung oder des Master-Servers schläft, bevor er eine Neuverbindung mit dem Master herzustellen versucht. Der entsprechende Wert in der Datei master.info hat ggf. Vorrang. Ist der Wert nicht angegeben, dann wird 60 als Vorgabe benutzt.

--master-host=host_name

Hostname oder IP-Adresse des Master-Replikationsservers. Der entsprechende Wert in der Datei master.info hat ggf. Vorrang. Ist kein Master-Host angegeben, dann wird der Slave-Thread nicht gestartet.

--master-info-file=file_name

Der Name der Datei, in der der Slave Angaben zum Master vermerkt. Der Standardname lautet mysql.info im Datenverzeichnis.

--master-password=password

Das Passwort des Kontos, welches der Slave zur Authentifizierung verwendet, wenn er sich beim Master anmeldet. Der entsprechende Wert in der Datei master.info hat ggf. Vorrang. Sofern nicht angegeben, wird ein leeres Passwort angenommen.

--master-port=port_number

Die Nummer des TCP/IP-Ports, auf dem der Master horcht. Der entsprechende Wert in der Datei master.info hat ggf. Vorrang. Sofern nicht angegeben, wird der einkompilierte Wert (normalerweise 3306) als Vorgabe verwendet.

--master-retry-count=count

Häufigkeit, mit der der Slave eine Neuverbindung mit dem Master probiert, bevor er aufgibt.

--master-ssl, --master-ssl-ca=file_name, --master-ssl-capath=directory_name, --master-ssl-cert=file_name, --master-ssl-cipher=cipher_list, --master-ssl-key=file_name

Diese Optionen werden zur Einstellung einer sicheren, SSL-verschlüsselten Replikationsverbindung zum Master-Server benutzt. Die Bedeutungen sind mit denen der entsprechenden Optionen --ssl, --ssl-ca, --ssl-capath, --ssl-cert, --ssl-cipher und --ssl-key identisch, die in Abschnitt 5.9.7.5, „SSL-Befehlsoptionen“, beschrieben werden. Die entsprechenden Werte in der Datei master.info haben ggf. Vorrang.

--master-user=user_name

Der Benutzername des Kontos, welches der Slave zur Authentifizierung verwendet, wenn er sich beim Master anmeldet. Dieses Konto benötigt die Berechtigung REPLICATION SLAVE. Der entsprechende Wert in der Datei master.info hat ggf. Vorrang. Wenn der Master-Benutzername nicht angegeben ist, wird der Name test als Vorgabe verwendet.

--max-relay-log-size=size

Größe, bei der der Server die Relay-Logs automatisch rotiert. Weitere Informationen finden Sie unter Abschnitt 6.4.4, „Relay- und Statusdateien bei der Replikation“.

--read-only

Bewirkt, dass der Slave keine Updates gestattet, sofern diese nicht von Slave-Threads oder von Benutzern mit der Berechtigung SUPER stammen. Auf diese Weise lässt sich sicherstellen, dass ein Slave-Server keine Aktualisierungen von Clients akzeptiert. Diese Option gilt nicht für TEMPORARY-Tabellen.

--relay-log=file_name

Der Name des Relay-Logs. Der Standardname lautet host_name-relay-bin.nnnnnn, wobei host_name der Name des Slave-Serverhosts ist und nnnnnn angibt, dass Relay-Logs mit fortlaufender Nummerierung erstellt werden. Sie können die Option angeben, um vom Hostnamen unabhängige Namen für Relay-Logs zu erstellen. Ferner ist sie praktisch, wenn Ihre Relay-Logs dazu tendieren, sehr groß zu werden (und Sie max_relay_log_size nicht verringern wollen), und Sie sie an einer anderen Position als im Datenverzeichnis ablegen müssen, oder wenn Sie die Geschwindigkeit durch eine Lastverteilung auf mehrere Festplatten optimieren wollen.

--relay-log-index=file_name

Der Name, der für die Indexdatei des Relay-Logs verwendet wird. Der Standardname lautet host_name-relay-bin.index im Datenverzeichnis, wobei host_name der Name des Slave-Servers ist.

--relay-log-info-file=file_name

Der Name der Datei, in der der Slave Angaben zu den Relay-Logs vermerkt. Der Standardname lautet relay-log.info im Datenverzeichnis.

--relay-log-purge={0|1}

Aktiviert oder deaktiviert das automatische Löschen von Relay-Logs, wenn sie nicht mehr benötigt werden. Der Vorgabewert ist 1 (aktiviert). Dies ist eine globale Variable, die dynamisch mit SET GLOBAL relay_log_purge = N geändert werden kann.

--relay-log-space-limit=size

Diese Option setzt eine Obergrenze für die Gesamtgröße aller Relay-Logs auf dem Slave, angegeben in Byte. Der Wert 0 hat die Bedeutung „unbeschränkt“. Die Option ist praktisch auf Slave-Servern, bei denen die Festplattenkapazität begrenzt ist. Wenn der Grenzwert erreicht wird, beendet der I/O-Thread das Auslesen von Ereignissen aus dem Binärlog des Masters, bis der SQL-Thread aufgeholt und eine Anzahl nicht mehr benötigter Relay-Logs gelöscht hat. Beachten Sie, dass das Limit nicht absolut ist: Es gibt Fälle, in denen der SQL-Thread mehr Ereignisse benötigt, bevor er Relay-Logs löschen kann. In diesem Fall überschreitet der I/O-Thread den Grenzwert so weit, wie es notwendig ist, damit der SQL-Thread einige Relay-Logs löschen kann (andernfalls würde der Slave nämlich blockiert). Sie sollten --relay-log-space-limit auf einen Wert setzen, der mindestens zweimal so groß ist wie der Wert von --max-relay-log-size (oder --max-binlog-size, sofern --max-relay-log-size 0 ist). In diesem Fall besteht die Möglichkeit, dass der I/O-Thread auf freien Speicher warten muss, weil --relay-log-space-limit überschritten wurde, der SQL-Thread aber kein Relay-Log löschen und deswegen die Anforderung des I/O-Threads nicht bearbeiten kann. Also ist der I/O-Thread gezwungen, --relay-log-space-limit vorübergehend zu ignorieren.

--replicate-do-db=db_name

Weist den Slave an, die Replikation auf Anweisungen zu beschränken, deren Standarddatenbank (also die von USE gewählte Datenbank) db_name ist. Um mehrere Datenbanken anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Datenbank). Beachten Sie, dass hierbei keine datenbankübergreifenden Anweisungen wie UPDATE some_db.some_table SET foo='bar' repliziert werden, solange eine andere Datenbank (oder gar keine Datenbank) gewählt ist.

Hier ein Beispiel für etwas, das nicht so funktioniert, wie Sie es vielleicht erwarten: Wenn der Slave mit der Option --replicate-do-db=sales gestartet wird und Sie die folgenden Anweisungen auf dem Master absetzen, wird die UPDATE-Anweisung nicht repliziert:

USE prices;
UPDATE sales.january SET amount=amount+1000;

Der wichtigste Grund für dieses Verhalten nach dem Motto „Nur die Standarddatenbank überprüfen“ besteht darin, dass es schwierig ist, allein der Anweisung zu entnehmen, ob sie repliziert werden soll (wenn Sie beispielsweise DELETE-Anweisungen für mehrere Tabellen oder UPDATE-Anweisungen für mehrere Tabellen verwenden, die datenbankübergreifend agieren). Außerdem geht es schneller, wenn nur die Standarddatenbank (statt aller Datenbanken) überprüft wird, sofern es keinen Grund dafür gibt.

Wenn Sie datenbankübergreifende Aktualisierungen zum Laufen bringen wollen, verwenden Sie stattdessen --replicate-wild-do-table=db_name.%. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

--replicate-do-table=db_name.tbl_name

Weist den Slave-Thread an, die Replikation auf die angegebene Tabelle zu beschränken. Um mehrere Tabellen anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Tabelle). Dies funktioniert – anders als --replicate-do-db – auch bei datenbankübergreifenden Änderungen. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

--replicate-ignore-db=db_name

Weist den Slave an, keine Anweisungen zu replizieren, deren Standarddatenbank (also die von USE gewählte Datenbank) db_name ist. Um mehrere zu ignorierende Datenbanken anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Datenbank). Sie sollten die Option allerdings nicht angeben, wenn Sie datenbankübergreifende Änderungen ausführen, die aber nicht repliziert werden sollen. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

Hier ein Beispiel für etwas, das nicht so funktioniert, wie Sie es vielleicht erwarten: Wenn der Slave mit der Option --replicate-ignore-db=sales gestartet wird und Sie die folgenden Anweisungen auf dem Master absetzen, wird die UPDATE-Anweisung nicht repliziert:

USE prices;
UPDATE sales.january SET amount=amount+1000;

Wenn Sie datenbankübergreifende Aktualisierungen zum Laufen bringen wollen, verwenden Sie stattdessen --replicate-wild-ignore-table=db_name.%. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

--replicate-ignore-table=db_name.tbl_name

Weist den Slave-Thread an, eine Anweisung, die die angegebene Tabelle ändert, auch dann nicht zu replizieren, wenn andere Tabellen von derselben Anweisung geändert werden könnten. Um mehrere zu ignorierende Tabellen anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Tabelle). Dies funktioniert – anders als --replicate-ignore-db – auch bei datenbankübergreifenden Änderungen. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

--replicate-rewrite-db=from_name->to_name

Weist den Slave an, die Standarddatenbank (also die von USE gewählte Datenbank) in to_name zu übersetzen, wenn sie auf dem Master den Namen from_name hatte. Hiervon sind nur tabellenbezogene Anweisungen betroffen (also keine Anweisungen wie CREATE DATABASE, DROP DATABASE und ALTER DATABASE), und diese auch nur dann, wenn from_name die Standarddatenbank auf dem Master ist. Dies funktioniert bei datenbankübergreifenden Änderungen nicht. Die Übersetzung des Datenbanknamens erfolgt vor dem Prüfen der --replicate-*-Regeln.

Wenn Sie diese Option auf der Befehlszeile verwenden und das Zeichen ‘>’ für Ihren Befehls-Interpreter ein Sonderzeichen ist, müssen Sie den Optionswert in Anführungszeichen setzen. Zum Beispiel:

shell> mysqld --replicate-rewrite-db="olddb->newdb"

--replicate-same-server-id

Wird auf Slave-Servern verwendet. Normalerweise sollten Sie die Standardeinstellung 0 verwenden, um durch eine Kreisreplikation verursachte Endlosschleifen zu verhindern. Wenn Sie den Wert 1 wählen, überspringt der Slave keine Ereignisse, die seine eigene Serverkennung enthalten – dies ist normalerweise nur in seltenen Fällen gewollt. Der Wert 1 kann bei Verwendung von --log-slave-updates nicht gewählt werden. Beachten Sie, dass der Slave-I/O-Thread standardmäßig noch nicht einmal dann Ereignisse aus dem Binärlog in das Relay-Log schreibt, wenn diese die Kennung des Slaves aufweisen (diese Optimierung hilft beim Einsparen von Festplattenkapazität). Wenn Sie also --replicate-same-server-id verwenden wollen, müssen Sie den Slave in jedem Fall mit dieser Option starten, bevor Sie ihn dazu bringen, eigene Ereignisse zu lesen, die der Slave-SQL-Thread ausführen soll.

--replicate-wild-do-table=db_name.tbl_name

Weist den Slave-Thread an, die Replikation auf Anweisungen zu beschränken, bei denen die aktualisierten Tabellen den angegebenen Mustern für Datenbank- und Tabellennamen entsprechen. Muster dürfen die Jokerzeichen ‘%’ und ‘_’ enthalten; diese haben dieselbe Bedeutung wie beim Mustervergleichsoperator LIKE. Um mehrere Tabellen anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Tabelle). Dies funktioniert bei datenbankübergreifenden Änderungen. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

Beispiel: --replicate-wild-do-table=foo%.bar% repliziert nur Updates, die eine Tabelle betreffen, bei der der Datenbankname mit foo und der Tabellenname mit bar beginnt.

Wenn als Muster für den Tabellennamen % angegeben wird, dann liegt eine Entsprechung für jeden Tabellennamen vor, und die Option gilt auch für Anweisungen auf Datenbankebene (CREATE DATABASE, DROP DATABASE und ALTER DATABASE). Wenn Sie beispielsweise --replicate-wild-do-table=foo%.% angeben, werden die Anweisungen auf Datenbankebene repliziert, wenn der Datenbankname foo% entspricht.

Um Jokerzeichen literal in den Mustern für Datenbank- oder Tabellennamen zu verwenden, kennzeichnen Sie sie mit einem Backslash. Um also beispielsweise alle Tabellen einer Datenbank namens my_own%db zu replizieren, nicht aber Tabellen aus my1ownAABCdb, sollten Sie die Zeichen ‘_’ und ‘%’ wie folgt kennzeichnen: --replicate-wild-do-table=my\_own\%db. Wenn Sie die Option auf der Befehlszeile angeben, müssen Sie unter Umständen je nach Befehls-Interpreter die Backslashes verdoppeln oder den Optionswert in Anführungszeichen setzen. So müssen Sie bei der bash-Shell etwa --replicate-wild-do-table=my\\_own\\%db angeben.

--replicate-wild-ignore-table=db_name.tbl_name

Weist den Slave-Thread an, eine Anweisung nicht zu replizieren, bei der eine beliebige Tabelle dem angegebenen Jokerzeichenmuster entspricht. Um mehrere zu ignorierende Tabellen anzugeben, verwenden Sie diese Option mehrfach (d. h. jeweils einmal pro Tabelle). Dies funktioniert bei datenbankübergreifenden Änderungen. Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.

Beispiel: --replicate-wild-ignore-table=foo%.bar% repliziert keine Updates, die eine Tabelle betreffen, bei der der Datenbankname mit foo und der Tabellenname mit bar beginnt.

Informationen zur Funktionsweise von Mustervergleichen entnehmen Sie der Beschreibung zur Option --replicate-wild-do-table. Die Regeln zur Verwendung literaler Jokerzeichen im Optionswert sind dieselben wie bei --replicate-wild-ignore-table.

--report-host=slave_name

Hostname oder IP-Adresse des Slaves, der oder die bei der Slave-Registrierung an den Master gemeldet wurde. Dieser Wert erscheint in der Ausgabe von SHOW SLAVE HOSTS auf dem Master-Server. Lassen Sie den Wert ungesetzt, wenn Sie nicht wollen, dass der Slave sich selbstständig beim Master registriert. Beachten Sie, dass es für den Master nicht ausreichend ist, die IP-Adresse des Slaves bei dessen Verbindungsherstellung einfach dem TCP/IP-Socket zu entnehmen. Aufgrund der Netzadressübersetzung (NAT) und anderer Routing-relevanter Probleme kann diese IP-Adresse unter Umständen nicht verwendet werden, um den Slave vom Master oder anderen Hosts aus zu kontaktieren.

--report-port=slave_port_num

Die Nummer des TCP/IP-Ports zur Verbindung mit dem Slave, die bei der Slave-Registrierung an den Master gemeldet wurde. Nehmen Sie die Einstellung nur vor, wenn der Slave nicht auch einem Standardport lauscht oder Sie einen speziellen Tunnel vom Master oder anderen Clients zum Slave verwenden. Wenn Sie sich nicht sicher sind, verwenden Sie die Option nicht.

--skip-slave-start

Weist den Slave-Server an, die Slave-Threads nicht zu starten, wenn der Server startet. Um die Threads später zu starten, können Sie die Anweisung START SLAVE verwenden.

--slave_compressed_protocol={0|1}

Wenn diese Option auf 1 gesetzt ist, wird eine Komprimierung des Slave/Master-Protokolls verwendet, wenn sowohl Slave als auch Master diese unterstützen.

--slave-load-tmpdir=file_name

Der Name des Verzeichnisses, in dem der Slave Temporärdateien erstellt. Diese Option entspricht standardmäßig dem Wert der Systemvariablen tmpdir. Wenn der Slave-SQL-Thread eine LOAD DATA INFILE-Anweisung repliziert, extrahiert er die zu ladende Datei aus dem Relay-Log in Temporärdateien und lädt diese dann in die Tabelle. Wenn die auf dem Master geladene Datei sehr groß ist, sind auch die Temporärdateien auf dem Slave groß. Aus diesem Grund kann es sich empfehlen, den Slave mit dieser Option anzuweisen, die Temporärdateien in ein Verzeichnis auf einem Dateisystem zu speichern, auf dem ausreichend viel Festplattenkapazität vorhanden ist. In diesem Fall sind auch die Relay-Logs riesig, weswegen Sie auch diese mit der Option --relay-log gleichermaßen auf jenem Dateisystem ablegen sollten.

Das mit dieser Option angegebene Verzeichnis sollte auf einem festplattenbasierten (d. h. nicht speicherresidenten) Dateisystem liegen, da die Temporärdateien, die zur Replikation von LOAD DATA INFILE verwendet werden, einen Systemneustart überdauern müssen. Das Verzeichnis sollte außerdem nicht eines sein, welches beim Systemstart vom Betriebssystem geleert wird.

--slave-net-timeout=seconds

Anzahl der Sekunden, für die auf weitere Daten vom Master gewartet wird, bevor der Slave die Verbindung als unterbrochen betrachtet, den Lesevorgang abbricht und eine Neuverbindung probiert. Der erste Versuch findet unmittelbar nach Überschreiten dieses Werts statt. Die Abstände zwischen den Neuversuchen werden von der Option --master-connect-retry gesteuert.

--slave-skip-errors=[err_code1,err_code2,...|all]

Normalerweise wird die Replikation beendet, wenn ein Fehler auf dem Slave auftritt. Sie haben auf diese Weise die Möglichkeit, Inkonsistenzen in den Daten manuell zu beheben. Diese Option weist den Slave-SQL-Thread an, mit der Replikation fortzufahren, wenn eine Anweisung einen der im Optionswert aufgeführten Fehler zurückgibt.

Verwenden Sie diese Option nicht, sofern Sie nicht genau wissen, warum Sie Fehler erhalten. Sind in Ihrer Replikationskonfiguration und Clientprogrammen ebenso wenig Fehler vorhanden wie Bugs in MySQL, dann sollte eigentlich nie ein Fehler auftreten, der die Replikation beendet. Die unüberlegte Verwendung dieser Option hat zur Folge, dass die Synchronisation zwischen Master und Slave unwiederbringlich verloren geht, ohne dass Sie überhaupt wissen, warum dies so ist.

Die Fehlercodes sind als Zahlenangaben in den Fehlermeldungen im Fehlerlog des Slaves und in der Ausgabe von SHOW SLAVE STATUS enthalten. Anhang B, Fehlercodes und -meldungen, listet die Serverfehlercodes auf.

Sie könnten theoretisch auch den nicht sehr empfehlenswerten Wert all angeben, damit der Slave alle Fehlermeldungen ignoriert und weiterarbeitet – egal, was auch passiert. Aber das sollten Sie besser lassen. Selbstredend gibt es, wenn Sie all verwenden, keine Garantie bezüglich der Datenintegrität. Sollten die Daten auf dem Slave in einem solchen Fall auch nicht annähernd denen auf dem Master entsprechen, so bitten wir von Beschwerden (und der Meldung von Bugs) abzusehen. Wir haben Sie gewarnt!

Ein paar Beispiele:

--slave-skip-errors=1062,1053
--slave-skip-errors=all