Die MySQL-Replikation basiert darauf, dass der Master-Server alle Änderungen an Ihren Datenbanken (Updates, Löschvorgänge usw.) in seinen Binärlogs vermerkt. Aus diesem Grund müssen Sie das binäre Loggen auf dem Master-Server aktivieren. Siehe auch Abschnitt 5.12.3, „Die binäre Update-Logdatei“.

Alle Slave-Server erhalten vom Master die gespeicherten Änderungen, die der Master in seinem Binärlog vermerkt hat, sodass jeder Slave dieselben Änderungen an seiner Kopie der Daten vornehmen kann.

Es ist extrem wichtig, sich klar zu machen, dass das Binärlog nichts anderes als eine Aufzeichnung darstellt, die zu genau dem Zeitpunkt beginnt, an dem Sie das binäre Loggen aktivieren. Insofern benötigen alle zu konfigurierenden Slaves Kopien der Master-Datenbank mit ihrem Aussehen zum Zeitpunkt der Aktivierung der Binärlogs auf dem Master. Wenn Sie Ihre Slaves mit Datenbanken starten, die nicht hundertprozentig denselben Status haben wie der Master beim Aktivieren der Binärlogs, dann werden höchstwahrscheinlich Probleme auftreten.

Eine Möglichkeit, die Daten des Masters auf den Slave zu kopieren, besteht im Absetzen der LOAD DATA FROM MASTER-Anweisung. Allerdings funktioniert LOAD DATA FROM MASTER nur, wenn alle Tabellen auf dem Master die MyISAM-Speicher-Engine verwenden. Ferner erwirkt die Anweisung eine globale Lesesperre, d. h., während die Tabellen auf den Slave übertragen werden, sind keine Updates auf dem Master möglich. Sobald wir die Funktion für sperrenfreie Tabellenbackups im laufenden Betrieb implementiert haben, wird diese globale Lesesperre nicht mehr erforderlich sein.

Aufgrund dieser Einschränkungen empfehlen wir Ihnen bis auf weiteres, LOAD DATA FROM MASTER nur dann zu verwenden, wenn die Datenmenge auf dem Master relativ gering oder eine längere Lesesperre auf dem Master hinnehmbar ist. Zwar kann die tatsächliche Geschwindigkeit von LOAD DATA FROM MASTER von System zu System variieren, aber als Faustregel können Sie eine Übertragungsrate von 1 Mbyte Daten/Sekunde erwarten. Dies ist ein grober Anhaltspunkt, der aber recht genau sein sollte, wenn sowohl Master als auch Slave über 700-MHz-Pentium-Prozessoren verfügen und über ein Netzwerk mit einer Übertragungsrate von 100 Mbit/s miteinander verbunden sind.

Nachdem auf dem Slave eine Kopie der Master-Daten installiert wurde, stellt er eine Verbindung zum Master her und wartet auf Updates, die er verarbeiten kann. Fällt der Master aus oder verliert der Slave die Verbindung zu ihm, dann versucht er in regelmäßigen Abständen, die Verbindung neu herzustellen, bis der Empfang von Updates wieder möglich ist. Die Option --master-connect-retry steuert das Intervall, in dem die Neuverbindung versucht wird. Voreingestellt sind 60 Sekunden.

Jeder Slave vermerkt die Position, an der das Lesen beim letzten Update vom Master-Server beendet wurde. Der Master selbst weiß nicht, wie viele Slaves an ihn angeschlossen sind oder welche Slaves zu einem gegebenen Zeitpunkt aktuell sind.