Die Robustheit wird durch eine Master/Slave-Konfiguration erhöht. Im Fall von Problemen auf dem Master können Sie auf den Slave als Sicherungskopie umschalten.

Eine verbesserte Reaktionszeit lässt sich für Clients erzielen, indem die Last bei der Verarbeitung von Clientabfragen auf die Master- und Slave-Server verteilt wird. SELECT-Abfragen können an einen Slave geschickt werden, um die Verarbeitungsbelastung des Masters zu senken. Allerdings sollten Anweisungen, die Daten verändern, in jedem Fall an den Master geschickt werden, damit die Synchronisation zwischen Master und Slaves erhalten bleibt. Die Lastverteilungsstrategie ist effizient, wenn in erster Linie nichtändernde Abfragen abgesetzt werden – aber dies ist auch der Normalfall.

Ein weiterer Vorteil der Replikation besteht darin, dass Sie Datenbanksicherungen über einen Slave-Server durchführen können, ohne den Master zu stören. Der Master verarbeitet dann weiterhin alle Aktualisierungen auch während der Erstellung des Backups. Siehe auch Abschnitt 5.10.1, „Datenbank-Datensicherungen“.

ANALYZE TABLE

REPAIR TABLE

OPTIMIZE TABLE

Die Replikation von AUTO_INCREMENT-, LAST_INSERT_ID()- und TIMESTAMP-Werten erfolgt korrekt.

Die Funktionen USER(), UUID() und LOAD_FILE() werden ohne Änderung repliziert und funktionieren daher nur dann korrekt auf dem Slave, wenn die datensatzbasierte Replikation aktiviert ist. (Siehe auch Abschnitt 6.3, „Zeilenbasierte Replikation“.)

Die folgende Beschränkung gilt nur für die anweisungsbasierte, nicht für die datensatzbasierte Replikation. Die Funktionen GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK() und IS_USED_LOCK(), die Sperren auf Benutzerebene verwalten, werden repliziert, ohne dass der Slave den zugehörigen Kontext auf dem Master kennt. Aus diesem Grund sollten diese Funktionen nicht zum Einfügen in eine Tabelle auf dem Master verwendet werde, da der Kontext auf dem Slave ganz anders aussehen würde. (So sollten Sie etwa keine Anweisung wie INSERT INTO mytable VALUES(GET_LOCK(...)) absetzen.)

Die Variablen FOREIGN_KEY_CHECKS, SQL_MODE, UNIQUE_CHECKS und SQL_AUTO_IS_NULL werden (ab MySQL 5.0) alle repliziert. Die Systemvariable storage_engine (die auch table_type heißt) wird in MySQL 5.1 noch nicht repliziert, was für die Replikation zwischen verschiedenen Speicher-Engines von Vorteil ist.

Die Replikation funktioniert zwischen Mastern und Slaves unter MySQL 5.0 und 5.1 in beliebiger Kombination – auch dann, wenn Master und Slave unterschiedliche Werte für die Zeichensatz- und/oder die globalen Zeitzonenvariablen aufweisen. (Beachten Sie, dass dies nicht in Fällen zutrifft, in denen Master und/oder Slave unter MySQL 4.1 oder früher laufen.)

Folgendes gilt für die Replikation zwischen MySQL Servern, die unterschiedliche Zeichensätze benutzen:

Wenn der Master MySQL 4.1 verwendet, dann sollte auf Master und Slave dieselbe Systemzeitzone eingestellt sein. Andernfalls werden einige Anweisungen – wie etwa solche, die die Funktionen NOW() oder FROM_UNIXTIME() verwenden – nicht korrekt repliziert. Sie können die Zeitzone, in der der MySQL Server läuft, mit der Option --timezone=timezone_name des Skripts mysqld_safe oder durch Einstellen der Umgebungsvariablen TZ ändern. Master und Slave sollten ferner auch dieselbe Standardeinstellung für die Verbindungszeitzone aufweisen, d. h., der Wert des Parameters --default-time-zone sollte auf Master und Slave gleich sein. Beachten Sie, dass dies nicht notwendig ist, wenn der Master unter MySQL 5.0 oder höher läuft.

CONVERT_TZ(...,...,@session.time_zone) wird nur dann korrekt repliziert, wenn Master und Slave unter MySQL 5.0.4 oder höher laufen.

Sitzungsvariablen werden nicht korrekt repliziert, wenn sie in Anweisungen verwendet werden, die Tabellen aktualisieren. So fügt SET MAX_JOIN_SIZE=1000 gefolgt von INSERT INTO mytable VALUES(@MAX_JOIN_SIZE) auf dem Master nicht dieselben Daten ein wie auf dem Slave. Dies betrifft allerdings nicht die gängige Sequenz aus SET TIME_ZONE=... gefolgt von INSERT INTO mytable VALUES(CONVERT_TZ(...,...,@time_zone)).

Die Replikation von Sitzungsvariablen ist kein Problem, wenn die datensatzbasierte Replikation benutzt wird. Siehe auch Abschnitt 6.3, „Zeilenbasierte Replikation“.

Es ist auch möglich, transaktionssichere Tabellen auf dem Master in nichttransaktionssichere Tabellen auf dem Slave zu replizieren. Sie können beispielsweise eine InnoDB-Tabelle auf dem Master als MyISAM-Tabelle auf dem Slave replizieren. Allerdings kommt es, wenn Sie dies tun, zu Problemen, wenn der Slave mitten in einem BEGIN/COMMIT-Block angehalten wird, weil er nachfolgend am Anfang des BEGIN-Blocks neu einstartet. Dieses Problem steht auf unserer Aufgabenliste und wird in Bälde behoben sein.

Änderungsanweisungen, die benutzerdefinierte Variablen (also Variablen des Typs @var_name) referenzieren, werden korrekt repliziert. (Dies gilt jedoch nicht für Versionen vor 4.1.) Beachten Sie, dass beginnend mit MySQL 5.0 bei den Namen von Benutzervariablen die Groß-/Kleinschreibung unterschieden wird, wenn Sie die Replikation zwischen MySQL 5.0 und älteren Versionen einrichten.

Slaves können unter Verwendung von SSL eine Verbindung zum Master herstellen.

Die globale Systemvariable slave_transaction_retries wirkt sich wie folgt auf die Replikation aus: Wenn ein SQL-Thread auf einem Replikationsslave eine Transaktion nicht ausführen kann, weil eine InnoDB-Blockade aufgetreten ist oder die Werte innodb_lock_wait_timeout von InnoDB bzw. TransactionDeadlockDetectionTimeout oder TransactionInactiveTimeout von NDBCluster überschritten wurden, erfolgt die durch slave_transaction_retries angegebene Anzahl von Neuversuchen, bevor der Vorgang mit einer Fehlermeldung beendet wird. Der Standardwert ist 10. Die Gesamtzahl der Neuversuche finden Sie in der Ausgabe von SHOW STATUS. (Siehe auch Abschnitt 5.2.4, „Server-Statusvariablen“.)

Wenn eine der Tabellenoptionen DATA DIRECTORY oder INDEX DIRECTORY in einer CREATE TABLE-Anweisung auf dem Master-Server verwendet wird, wird dieselbe Option auch auf dem Slave umgesetzt. Dies kann zu Problemen führen, wenn im Dateisystem des Slave-Hosts kein entsprechendes Verzeichnis vorhanden ist, oder wenn es zwar vorhanden ist, aber der Slave-Server nicht darauf zugreifen kann. MySQL unterstützt eine sql_mode-Option namens NO_DIR_IN_CREATE. Wenn dieser SQL-Modus am Slave-Server aktiviert ist, ignoriert der Slave die Tabellenoptionen DATA DIRECTORY und INDEX DIRECTORY beim Replizieren von CREATE TABLE-Anweisungen. Infolgedessen werden die MyISAM-Daten- und Indexdateien im Datenbankverzeichnis der Tabelle erstellt.

Die folgende Beschränkung betrifft nur die anweisungsbasierte Replikation, nicht die datensatzbasierte Replikation: Die Daten auf dem Master und dem Slave können verschieden werden, wenn eine Abfrage so formuliert wird, dass die Datenänderung nichtdeterministisch ist, d. h. dem Gutdünken des Abfrageoptimierers überlassen wird. (Dies ist auch abgesehen von der Replikation nicht zu empfehlen.) Eine umfassende Erläuterung dieses Problems finden Sie unter Abschnitt A.8.1, „Offene Probleme in MySQL“.

FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE und FLUSH TABLES WITH READ LOCK werden nicht geloggt, weil dies bei der Replikation auf einen Slave Probleme verursachen würde. Ein Syntaxbeispiel finden Sie in Abschnitt 13.5.5.2, „FLUSH“. Die Anweisungen FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE und REPAIR TABLE werden in das Binärlog geschrieben und infolgedessen auf die Slaves repliziert. Dies ist normalerweise unproblematisch, weil diese Anweisungen die Tabellendaten nicht verändern. Allerdings kann dies unter bestimmten Umständen trotzdem Probleme verursachen. Wenn Sie die Berechtigungstabellen in der mysql-Datenbank replizieren und diese Tabellen direkt und ohne Verwendung von GRANT aktualisieren, müssen Sie eine FLUSH PRIVILEGES-Anweisung auf den Slaves absetzen, damit die neuen Berechtigungen gültig werden. Ferner müssen Sie, wenn Sie FLUSH TABLES beim Umbenennen einer MyISAM-Tabelle absetzen, die Teil einer MERGE-Tabelle ist, auf den Slaves eine FLUSH TABLES-Anweisung manuell absetzen. Diese Anweisungen werden in das Binärlog geschrieben, sofern Sie nicht NO_WRITE_TO_BINLOG oder den Alias LOCAL angegeben haben.

MySQL unterstützt genau einen Master und mehrere Slaves. Zukünftig beabsichtigen wir, einen Votieralgorithmus hinzuzufügen, der den Master automatisch wechselt, falls Probleme in Verbindung mit dem aktuellen Master auftreten. Ferner werden wir Agentenprozesse zur Durchführung einer Lastverteilung implementieren, indem SELECT-Anweisungen an verschiedene Slaves gesendet werden.

Wenn ein Server heruntergefahren wird und neu startet, werden seine MEMORY-Tabellen geleert. Der Master repliziert diesen Effekt wie folgt auf seine Slaves: Wenn der Master eine MEMORY-Tabelle nach dem Start zum ersten Mal verwendet, loggt er ein Ereignis, welches den Slaves angibt, dass die Tabelle geleert werden muss, indem eine DELETE-Anweisung für die betreffende Tabelle in das Binärlog geschrieben wird. Weitere Informationen finden Sie in Abschnitt 14.4, „Die MEMORY-Speicher-Engine“.

Beachten Sie, dass das Folgende nicht gilt, wenn die datensatzbasierte Replikation verwendet wird, denn diese erfordert überhaupt keine Replikation von Temporärtabellen. (Siehe auch Abschnitt 6.3, „Zeilenbasierte Replikation“.)

Temporärtabellen werden normalerweise repliziert. Eine Ausnahme liegt vor, wenn Sie den Slave-Server (und nicht nur die Slave-Threads) heruntergefahren und Temporärtabellen repliziert haben, die in Updates verwendet werden, welche noch nicht auf dem Slave ausgeführt wurden. Haben Sie den Slave-Server heruntergefahren, dann stehen die Temporärtabellen, die von diesen Aktualisierungen benötigt werden, beim Neustart des Servers nicht mehr zur Verfügung. Um dieses Problem zu umgehen, fahren Sie den Slave nicht herunter, solange Temporärtabellen geöffnet sind. Stattdessen wenden Sie folgende Vorgehensweise an:

Die Verbindung mit Servern in einer Master/Slave-Zirkelbeziehung ist sicher, wenn Sie die Option --log-slave-updates benutzen. Das bedeutet, dass Sie eine Konfiguration wie die folgende erstellen können:

A -> B -> C -> A

Allerdings funktionieren viele Anweisungen in einer solchen Konfiguration nicht einwandfrei, sofern Ihr Code nicht so formuliert ist, dass potenzielle Probleme berücksichtigt werden, die aufgrund von auf verschiedenen Servern in unterschiedlicher Reihenfolge durchgeführten Updates entstehen können.

Serverkennungen werden in Binärlogereignisse kodiert, d. h., Server A erkennt, wenn ein Ereignis, das er liest, ursprünglich von ihm selbst erstellt worden ist, und führt es dann nicht aus (es sei denn, Server A wurde mit der Option --replicate-same-server-id gestartet, die aber nur in wenigen Fällen wichtig ist). Es kommt also nicht zu Endlosschleifen. Eine solche Zirkelkonfiguration funktioniert nur, wenn Sie keine Updates durchführen, durch die es zu Konflikten zwischen Tabellen kommt: Wenn Sie Daten sowohl auf A als auch auf C einfügen, sollten Sie keinesfalls einen Datensatz auf A einfügen, dessen Schlüssel unter Umständen mit einem Datensatz auf C kollidiert. Ebenso wenig sollten Sie dieselben Datensätze auf zwei Servern aktualisieren, wenn die Reihenfolge, in der die Updates durchgeführt werden, von Bedeutung ist.

Wenn eine Anweisung auf einem Slave einen Fehler erzeugt, wird der Slave-SQL-Thread terminiert, und der Slave schreibt eine Meldung in sein Fehlerlog. In diesem Fall sollten Sie manuell eine Verbindung zum Slave herstellen und die Ursache des Problems bestimmen. (Hierfür ist SHOW SLAVE STATUS recht praktisch.) Danach beheben Sie das Problem (z. B. durch Erstellen einer nichtvorhandenen Tabelle) und führen dann START SLAVE aus.

Einen Master-Server herunterzufahren und später neu zu starten ist sicher. Wenn ein Slave seine Verbindung zum Master verliert, versucht er sofort eine Neuverbindung und wiederholt diesen Versuch in regelmäßigen Abständen, bis er erfolgreich ist. Standardmäßig erfolgt alle 60 Sekunden ein Versuch zur Neuverbindung. Dies lässt sich mit der Option --master-connect-retry ändern. Ein Slave kann auch mit Ausfällen der Netzwerkkonnektivität zurechtkommen. Allerdings bemerkt er einen solchen Ausfall erst, wenn er für slave_net_timeout Sekunden keine Daten vom Master empfangen hat. Sind die Ausfälle kurz, dann sollten Sie den Wert von slave_net_timeout verringern. Siehe auch Abschnitt 5.2.2, „Server-Systemvariablen“.

Das (saubere) Herunterfahren des Slaves ist auch sicher, weil er vermerkt, an welcher Stelle er beendet wurde. Unsauberes Herunterfahren hingegen kann insbesondere dann Probleme verursachen, wenn der Festplatten-Cache vor Terminierung des Systems nicht auf die Festplatte geschrieben worden war. Ihre Systemfehlertoleranz erhöht sich erheblich, wenn Sie eine gute unterbrechungsfreie Stromversorgung verwenden. Eine unsaubere Beendigung des Masters kann Inkonsistenzen zwischen dem Inhalt der Tabellen und dem Binärlog auf dem Master zur Folge haben. Dies lässt sich durch Verwendung von InnoDB-Tabellen und der Option --innodb-safe-binlog auf dem Master vermeiden. Siehe auch Abschnitt 5.12.3, „Die binäre Update-Logdatei“.

Hinweis: --innodb-safe-binlog wird in MySQL 5.1 nicht benötigt, weil es durch die in MySQL 5.0 eingeführte Unterstützung von XA-Transaktionen obsolet geworden ist. Siehe auch Abschnitt 13.4.7, „XA-Transaktionen“.

Aufgrund des nichttransaktionssicheren Wesens von MyISAM-Tabellen kann es vorkommen, dass eine Anweisung eine Tabelle nur teilweise aktualisiert und dann einen Fehlercode zurückgibt. Dies kann beispielsweise beim Einfügen mehrerer Datensätze geschehen, wenn einer dieser Datensätze gegen einen Schlüssel-Constraint verstößt, oder wenn eine lange Update-Anweisung nach Aktualisierung einer Anzahl von Datensätzen terminiert wurde. Wenn dies auf dem Master passiert, wird der Slave-Thread beendet. Es liegt dann am Datenbankadministrator, zu entscheiden, was zu tun ist, sofern der Fehlercode nicht zulässig ist und die Ausführung der Anweisung auf dem Slave denselben Fehlercode verursacht. Wenn dieses Verhalten der Fehlercodeauswertung nicht gewünscht ist, können einige oder alle Fehler mit der Option --slave-skip-errors maskiert (d. h. ignoriert) werden.

Wenn Sie transaktionssichere Tabellen aus nichttransaktionssicheren Tabellen in einer BEGIN/COMMIT-Sequenz aktualisieren, sind die Änderungen im Binärlog unter Umständen nicht synchron zu den Tabellenzuständen, wenn die nichttransaktionssichere Tabelle aktualisiert wird, bevor die Transaktion übergeben wird. Die Ursache hierfür ist, dass die Transaktion erst dann in das Binärlog geschrieben wird, wenn sie übergeben wird.

In Situationen, in denen Transaktionen Updates für transaktionssichere und nichttransaktionssichere Tabellen vermischen, ist die Reihenfolge der Anweisungen im Binärlog korrekt, und alle erforderlichen Anweisungen werden – auch bei einem Rollback – in das Binärlog geschrieben. Aktualisiert allerdings eine zweite Verbindung die nichttransaktionssichere Tabelle, bevor die Transaktion der ersten Verbindung abgeschlossen ist, dann kann die geloggte Anweisungsreihenfolge falsch sein, weil die Änderung der zweiten Verbindung unmittelbar nach ihrer Ausführung geschrieben wird – unabhängig von dem Zustand der Transaktion, die von der ersten Verbindung durchgeführt wurde.

--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

safe_writer_connect()

safe_reader_connect()

safe_reader_statement()

safe_writer_statement()

Wenn N = 0 ist (d. h. keine Replikation), dann kann unser System ca. 1200 ÷ 11 = 109 Schreiboperationen pro Sekunde verarbeiten.

Bei N = 1 sind 184 Schreiboperationen pro Sekunde möglich.

Bei N = 8 sind 400 Schreiboperationen pro Sekunde möglich.

Bei N = 17 sind 480 Schreiboperationen pro Sekunde möglich.

Schließlich kommen wir, je mehr sich N der Unendlichkeit (und unserem Budget der negativen Unendlichkeit) annähert, auf einen Wert von 600 Schreiboperationen pro Sekunde, während wir unseren Systemdurchsatz etwa auf das 5,5fache gesteigert haben. Bei nur acht Servern beträgt die Steigerung hingegen knapp das Vierfache.

Welches Verhältnis besteht zwischen Lese- und Schreiboperationen auf Ihrem System?

Wie viel mehr Schreiboperationen kann ein Server verarbeiten, wenn Sie die Anzahl der Leseoperationen verringern?

Wie viele Slaves unterstützt die Bandbreite in Ihrem Netzwerk?

Verwenden Sie die CHANGE MASTER TO-Anweisung, um einen Slave anzuweisen, den Master zu wechseln.

Eine gute Möglichkeit, Ihre Anwendungen bezüglich des Standorts des Masters auf dem aktuellen Stand zu halten, ist die Verwendung eines dynamischen DNS-Eintrags für den Master. Bei bind können Sie nsupdate verwenden, um Ihr DNS dynamisch zu aktualisieren.

Starten Sie Ihre Slaves mit der Option --log-bin und ohne die Option --log-slave-updates. Auf diese Weise ist ein Slave in der Lage, zum Master zu werden, sobald Sie die Anweisungen STOP SLAVE, RESET MASTER und CHANGE MASTER TO auf anderen Slaves absetzen. Angenommen, wir hätten folgende Konfiguration:

       WC
        \
         v
 WC----> M
       / | \
      /  |  \
     v   v   v
    S1   S2  S3

In diesem Diagramm bezeichnet M den Master, S die Slaves und WC die Clients, die Schreib- und Lesevorgänge an die Datenbank absetzen. (Clients, die nur aus der Datenbank lesen, sind nicht vorhanden, da bei ihnen keine Änderungen erforderlich sind.) S1, S2 und S3 sind Slaves, die mit der Option --log-bin und ohne --log-slave-updates laufen. Da die von einem Slave empfangenen Updates nicht im Binärlog vermerkt werden, sofern nicht die Option --log-slave-updates angegeben ist, sind die Binärlogs auf den Slaves anfangs leer. Fällt nun M aus irgendeinem Grund aus, dann können Sie einen der Slaves auswählen, der dann der neue Master wird. Wenn Sie also etwa S1 auswählen, sollten alle WC auf S1 umgelenkt werden, der die Updates in sein Binärlog schreibt. S2 und S3 replizieren nachfolgend von S1.

Sinn der Ausführung des Slaves ohne --log-slave-updates ist es, zu verhindern, dass Slaves Updates zweimal erhalten, was vorkommen kann, wenn einer der Slaves zum neuen Master wird. Nehmen wir einmal an, bei S1 wäre die Option --log-slave-updates aktiviert. Er schreibt nun Updates, die er von M empfängt, in sein eigenes Binärlog. Wenn S2 von M auf S1 also umschaltet, empfängt er Updates von S1, die er bereits von M erhalten hat.

Stellen Sie sicher, dass alle Slaves alle Anweisungen im jeweiligen Relay-Log verarbeitet haben. Setzen Sie auf jedem Slave STOP SLAVE IO_THREAD ab und suchen Sie dann in der Ausgabe von SHOW PROCESSLIST die Angabe Has read all relay log. Wenn dieser Zustand von allen Slaves erreicht wurde, können sie auf die neue Konfiguration umgestellt werden. Auf dem Slave S1, der neuer Master werden soll, setzen Sie STOP SLAVE und RESET MASTER ab.

Auf den anderen Slaves S2 und S3 setzen Sie STOP SLAVE und CHANGE MASTER TO MASTER_HOST='S1' ab (wobei 'S1' den echten Hostnamen von S1 darstellt). Zu CHANGE MASTER fügen Sie nun alle Informationen darüber hinzu, wie von S2 oder S3 aus eine Verbindung mit S1 hergestellt wird (also user, password, port). Sie müssen in CHANGE MASTER den Namen des Binärlogs von S1 oder der Binärlogposition, ab der gelesen werden soll, nicht angeben. Wir wissen, dass es das erste Binärlog und die Position 4 ist (dies sind die Standardwerte von CHANGE MASTER). Abschließend setzen Sie START SLAVE auf S2 und S3 ab.

Nun weisen Sie alle WC an, ihre Anweisung an S1 zu leiten. Von diesem Punkt an werden alle Updateanweisungen, die von WC an S1 gesendet werden, in das Binärlog von S1 geschrieben, welches dann alle Updateanweisungen enthält, die seit dem Ausfall von M an S1 gesendet wurden.

Das Ergebnis ist folgende Konfiguration:

       WC
      /
      |
 WC   |  M(unavailable)
  \   |
   \  |
    v v
     S1<--S2  S3
      ^       |
      +-------+

Wenn M wieder betriebsbereit ist, müssen Sie darauf dieselbe CHANGE MASTER-Anweisung absetzen, die Sie auf S2 und S3 verwendet haben, damit M ein Slave von S1 wird und alle WC-Schreiboperationen empfängt, die er seit dem Ausfall verpasst hat. Um M wieder zum Master zu machen (etwa weil es sich dabei um das leistungsfähigste System handelt), verwenden Sie die beschriebene Methode erneut und tun dabei so, als ob S1 nicht mehr verfügbar wäre und M nun zum neuen Master wird. Während dieses Vorgangs dürfen Sie nicht vergessen, RESET MASTER auf M auszuführen, bevor Sie S1, S2 und S3 zu Slaves von M machen. Andernfalls empfangen diese Server alte WC-Schreiboperationen, die abgesetzt wurden, bevor M ausfiel.

Bewährte Technologie, seit MySQL 3.23 vorhanden.

Kleinere Logdateien. Wenn Änderungs- oder Löschvorgänge viele Datensätze betreffen, sind die Logdateien wesentlich kleiner. Kleinere Logdateien erfordern weniger Speicherplatz und sind schneller gesichert.

Logdateien enthalten alle Anweisungen, mit denen Änderungen vorgenommen wurden, d. h., sie können zur Überwachung der Datenbank verwendet werden.

Logdateien können nicht nur zu Replikationszwecken, sondern auch zur Point-in-Time-Wiederherstellung verwendet werden. Siehe auch Abschnitt 5.10.3, „Zeitpunktbezogene Wiederherstellung“.

Ein Slave kann eine neuere MySQL-Version mit einer anderen Datensatzstruktur verwenden.

Nicht alle UPDATE-Anweisungen können repliziert werden: Jedes nichtdeterministische Verhalten (z. B. bei der Verwendung von Zufallsfunktionen in einer SQL-Anweisung) ist bei der anweisungsbasierten Replikation schwer zu replizieren. Bei Anweisungen, die eine nichtdeterministische benutzerdefinierte Funktion (User-Defined Function, UDF) verwenden, ist die Replikation des Ergebnisses bei der anweisungsbasierten Replikation überhaupt nicht möglich (dagegen repliziert die datensatzbasierte Replikation einfach den von der UDF zurückgegebenen Wert).

Anweisungen können nicht korrekt repliziert werden, wenn sie eine UDF verwenden, die nichtdeterministisch ist (d. h. deren Wert von anderen Aspekten als den übergebenen Parametern abhängt).

Anweisungen können nicht korrekt repliziert werden, wenn sie eine der folgenden Funktionen enthalten:

Alle übrigen Funktionen (einschließlich RAND(), NOW(), LOAD DATA INFILE usw.) werden korrekt repliziert.

INSERT ... SELECT erfordert eine höhere Zahl von Sperren auf Datensatzebene als bei der datensatzbasierten Replikation.

UPDATE-Anweisungen, die einen Tabellenscan erfordern (weil in der WHERE-Klausel kein Index verwendet wird), müssen eine höhere Anzahl von Datensätzen sperren als bei der datensatzbasierten Replikation.

(Nur bei InnoDB) Eine INSERT-Anweisung, die AUTO_INCREMENT verwendet, blockiert andere, nicht kollidierende INSERT-Anweisungen.

Langsamere Umsetzung von Daten auf dem Slave bei komplexen Abfragen.

Gespeicherte Funktionen (nicht aber gespeicherte Prozeduren) werden mit demselben NOW()-Wert wie die aufrufende Anweisung ausgeführt. (Dies kann abhängig von den Umständen ein Vor- oder Nachteil sein.)

Deterministische UDFs müssen auf die Slaves angewendet werden.

Wenn am Slave etwas nicht stimmt, nehmen die Unterschiede zwischen Master und Slave im Laufe der Zeit zu.

Tabellen müssen auf dem Master und dem Slave (fast) identisch sein.

Alles kann repliziert werden. Dies ist die sicherste Form der Replikation. Beachten Sie, dass zurzeit DDL-Anweisungen (Data Definition Language) wie etwa CREATE TABLE anweisungsbasiert repliziert werden, während bei DML-Anweisungen (Data Manipulation Language) sowie bei GRANT- und REVOKE-Anweisungen die Replikation datensatzbasiert erfolgt. Für Anweisungen wie CREATE ... SELECT wird eine CREATE-Anweisung aus der Tabellendefinition erstellt, die dann anweisungsbasiert repliziert wird, während das Einfügen von Datensätzen datensatzbasiert repliziert wird.

Die Technologie ist dieselbe wie bei den meisten anderen Datenbanksystemen – Kenntnisse anderer Systeme lassen sich einfach auf MySQL übertragen.

In vielen Fällen geht es bei Tabellen mit Primärschlüsseln schneller, wenn man die Daten auf den Slave anwendet.

Bei den folgenden Anweisungstypen werden weniger Sperren auf dem Master benötigt (was die Nebenläufigkeit erhöht):

Weniger Sperren auf dem Slave bei INSERT-, UPDATE- oder DELETE-Anweisungen.

Es ist möglich, mehrere Threads hinzuzufügen, um Daten zukünftig auf den Slave anzuwenden (dies funktioniert bei SMP-Systemen besser).

Größere Logdateien (in manchen Fällen sogar wesentlich größer).

Das Binärlog enthält Daten für umfangreiche Anweisungen, die per Rollback rückgängig gemacht wurden.

Wenn Sie mit der datensatzbasierten Replikation eine Anweisung (z. B. eine UPDATE- oder DELETE-Anweisung) replizieren, muss jeder geänderte Datensatz in das Binärlog geschrieben werden. Im Gegensatz dazu wird bei Verwendung der anweisungsbasierten Replikation nur die Anweisung in das Binärlog geschrieben. Wenn die Anweisung viele Datensätze ändert, schreibt die datensatzbasierte Replikation deutlich mehr Daten in das Binärlog. In diesem Fall wird das Binärlog für eine längere Zeit gesperrt, um die Daten schreiben zu können, was Probleme mit der Nebenläufigkeit verursachen kann.

Deterministische UDFs, die große BLOB-Werte erzeugen, werden merklich langsamer repliziert.

Sie können die Logs darauf überprüfen, welche Anweisungen ausgeführt wurden.

Sie können auf dem Slave nicht nachprüfen, welche Anweisungen vom Master empfangen und dann ausgeführt wurden.

Überprüfen Sie, ob am Master das binäre Loggen aktiviert ist, indem Sie eine SHOW MASTER STATUS-Anweisung absetzen. Bei aktiviertem Loggen ist Position ungleich null. Sollte das binäre Loggen nicht aktiviert sein, dann stellen Sie sicher, dass der Master mit den Optionen --log-bin und --server-id läuft.

Überprüfen Sie, ob der Slave ausgeführt wird. Mit SHOW SLAVE STATUS können Sie feststellen, ob die Werte von Slave_IO_Running und Slave_SQL_Running jeweils Yes lauten. Andernfalls überprüfen Sie die Optionen, die beim Start des Slave-Servers angegeben waren. So verhindert etwa --skip-slave-start, dass die Slave-Threads gestartet werden, bis Sie eine START SLAVE-Anweisung absetzen.

Wird der Slave ausgeführt, dann prüfen Sie, ob er eine Verbindung zum Master herstellen konnte. Setzen Sie SHOW PROCESSLIST ab, suchen Sie die I/O- und SQL-Threads und überprüfen Sie die zugehörigen State-Spalten. Siehe auch Abschnitt 6.4, „Replikation: Implementationsdetails“. Wenn für den I/O-Thread als Status Connecting to master angegeben ist, überprüfen Sie die Berechtigungen für den Replikationsbenutzer auf dem Master, den Hostnamen des Masters und Ihre DNS-Konfiguration und stellen Sie sicher, dass der Master ausgeführt wird und auch vom Slave erreicht werden kann.

Wurde der Slave bereits vorher ausgeführt, dann aber beendet, dann liegt das in der Regel daran, dass irgendeine Anweisung, die auf dem Master erfolgreich verarbeitet wurde, auf dem Slave fehlgeschlagen ist. Dies sollte niemals passieren, wenn Sie eine korrekte Momentaufnahme auf dem Master erstellt und die Daten auf dem Slave niemals außerhalb des Slave-Threads modifiziert haben. Wird der Slave unerwartet beendet, dann liegt entweder ein Bug vor, oder Sie sind auf eine der bekannten Einschränkungen der Replikation gestoßen, die in Abschnitt 6.8, „Replikation: Features und bekannte Probleme“, beschrieben sind. Wenn es sich um einen Bug handelt, lesen Sie Abschnitt 6.14, „Berichten von Replikationsfehlern und -problemen“, um zu erfahren, wie Sie diesen melden.

Wenn eine Anweisung, die auf dem Master klaglos verarbeitet wurde, nicht auf dem Slave ausgeführt werden kann, probieren Sie folgende Vorgehensweise aus, sofern die Durchführung einer vollständigen Datenbankneusynchronisierung durch Löschen der Datenbanken auf dem Slave und Kopieren einer neuen Momentaufnahme vom Master nicht realisierbar ist:

auto_increment_increment steuert das Intervall zwischen aufeinander folgenden AUTO_INCREMENT-Werten.

auto_increment_offset bestimmt den Startwert der Spalte AUTO_INCREMENT.

Setzen Sie auto_increment_increment auf jedem Master auf N.

Stellen Sie auf jedem der N Master einen unterschiedlichen Wert für auto_increment_offset ein (0, 1, 2, … , N – 1).