Dieser Abschnitt beschreibt die Optionen, die Sie auf Replikationsslaves verwenden können. Sie können diese Optionen wahlweise auf der Befehlszeile oder in einer Optionsdatei angeben.
Auf dem Master und jedem Slave müssen Sie die Option
server-id
angeben, um eine eindeutige
Replikationskennung zu erstellen. Wählen Sie auf jedem Server
eine eindeutige Zahl zwischen 1 und 232
– 1. Außerdem muss jede Kennung sich von jeder anderen
Kennung unterscheiden. Zum Beispiel:
server-id=3
Optionen, die Sie auf dem Master-Server zur Steuerung des binären Loggens verwenden können, sind in Abschnitt 5.12.3, „Die binäre Update-Logdatei“, beschrieben.
Einige Replikationsoptionen für Slave-Server werden in dem Sinne
speziell gehandhabt, dass sie ignoriert werden, wenn beim Start
des Slaves eine Datei master.info
vorhanden
ist und diese einen Wert für die betreffende Option enthält.
Dies betrifft die folgenden Optionen:
--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
Die Datei master.info
in MySQL
5.1 enthält Werte, die den SSL-Optionen entsprechen.
Daneben sieht das Format dieser Datei in der ersten Zeile auch die
Nennung der Gesamtanzahl aller Zeilen in der Datei vor. Wenn Sie
einen älteren Server (vor MySQL 4.1.1) auf eine neuere Version
aktualisieren, setzt der neue Server die Datei
master.info
beim Start automatisch auf das
neue Format. Wenn Sie hingegen ein Downgrade auf einen älteren
Server durchführen, sollten Sie die erste Zeile manuell
entfernen, bevor Sie den älteren Server zum ersten Mal starten.
Ist beim Start des Slave-Servers keine Datei
master.info
vorhanden, dann werden für diese
Optionen die Werte verwendet, die in Optionsdateien oder auf der
Befehlszeile angegeben wurden. Dies ist etwa der Fall, wenn Sie
den Server zum ersten Mal als Replikationsslave starten, oder wenn
Sie RESET SLAVE
ausgeführt haben und den Slave
nun herunterfahren und neu starten.
Ist die Datei master.info
beim Start des
Slaves vorhanden, dann verarbeitet der Server ihren Inhalt und
ignoriert Werte, die für die in der Datei aufgeführten Optionen
übergeben wurden. Wenn Sie den Slave-Server also mit anderen
Werten für die Startoptionen starten als denen in der Datei
master.info
, dann haben die von Ihnen
übergebenen Werte keine Auswirkung, weil der Server die Angaben
der Datei master.info
entnimmt. Um andere
Werte verwenden zu können, müssen Sie entweder nach dem
Entfernen der Datei master.info
einen
Neustart durchführen oder die Werte bei laufendem Slave-Server
mit der Anweisung CHANGE MASTER TO
zurücksetzen (Letztere ist die empfohlene Methode).
Angenommen, Sie geben folgende Option in Ihrer Datei
my.cnf
an:
[mysqld]
master-host=some_host
Wenn Sie den Server zum ersten Mal als Replikationsslave starten,
liest und verwendet er diese Option aus der Datei
my.cnf
. Danach zeichnet der Server den Wert
in der Datei master.info
auf. Wenn Sie den
Server beim nächsten Mal starten, liest er den Master-Hostwert
nur aus der Datei master.info
und ignoriert
den Wert in der Optionsdatei. Wenn Sie später in der Datei
my.cnf
den anderen Master-Host
some_other_host
angeben, hat diese
Änderung keine Auswirkungen. Sie müssen stattdessen
CHANGE MASTER TO
verwenden.
Da der Server einer vorhandenen Datei
master.info
Vorrang vor den gerade
beschriebenen Startoptionen gewährt, sollten Sie diese Werte
unter Umständen überhaupt nicht mit Startoptionen angeben,
sondern sie stattdessen mit der CHANGE MASTER
TO
-Anweisung festlegen. Siehe auch
Abschnitt 13.6.2.1, „CHANGE MASTER TO
“.
Dieses Beispiel zeigt eine etwas umfangreichere Nutzung der Startoptionen zur Konfiguration eines Slave-Servers:
[mysqld] server-id=2 master-host=db-master.mycompany.com master-port=3306 master-user=pertinax master-password=freitag master-connect-retry=60 report-host=db-slave.mycompany.com
Die folgende Liste beschreibt die Startoptionen zur Steuerung der
Replikation. Viele dieser Optionen können bei laufendem Server
mit der Anweisung CHANGE MASTER TO
zurückgesetzt werden. Andere wie beispielsweise die
--replicate-*
-Optionen können nur beim Start des
Slave-Servers zurückgesetzt werden. Wir beabsichtigen dies zu
beheben.
--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
,
wobei host_name
-relay-bin.nnnnnn
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
im Datenverzeichnis, wobei
host_name
-relay-bin.indexhost_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 =
geändert werden kann.
N
--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
repliziert werden, solange eine andere
Datenbank (oder gar keine Datenbank) gewählt ist.
some_db.some_table
SET
foo='bar'
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=
.
Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.
db_name
.%
--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=
.
Siehe auch Abschnitt 6.10, „Wie Server Replikationsregeln auswerten“.
db_name
.%
--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
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.