MySQL unterstützt die unidirektionale und asynchrone Replikation Der Server fungiert als Master-Server. Ein oder mehrere andere Server fungieren als Slave-Server. Der Masterserver schreibt Aktualisierungen in binäre Protokolldateien und verwaltet einen Index der Protokolldateien, um die Protokollrotation zu verfolgen. Wenn ein Slave eine Verbindung zum Master herstellt, benachrichtigt er den Master über den Ort der letzten erfolgreichen Aktualisierung, die der Slave im Protokoll gelesen hat. Der Slave-Server empfängt alle seitdem erfolgten Updates, blockiert dann und wartet darauf, dass der Master-Server das nächste Update benachrichtigt.
Warum Master-Slave-Replikation verwenden?
1. Die Einstellung Master-Server/Slave-Server erhöht die Robustheit. Wenn mit dem Master-Server etwas schief geht, können Sie als Backup auf den Slave-Server wechseln.
2. Durch die Aufteilung der Verarbeitungslast der Kundenanfragen zwischen dem Master-Server und dem Slave-Server können Sie eine bessere Antwortzeit für den Kunden erzielen. Führen Sie jedoch nicht gleichzeitig Updates auf dem Master- und dem Slave-Server durch, da dies zu Konflikten führen kann.
3. Ein weiterer Vorteil der Replikation besteht darin, dass Sie einen Slave-Server zum Durchführen von Sicherungen verwenden können, ohne den Master-Server zu stören. Der Master-Server kann während des Backup-Vorgangs weiterhin Aktualisierungen verarbeiten.
MySQL verwendet 3 Threads, um Replikationsfunktionen auszuführen (1 auf dem Master-Server und zwei auf dem Slave-Server). Wenn ein START SLAVE ausgegeben wird, erstellt der Slave-Server einen E/A-Thread, um eine Verbindung zum Master-Server herzustellen und den Master-Server Binärdateien senden zu lassen log. Der Master-Server erstellt einen Thread, um den Inhalt des Binärprotokolls an den Slave-Server zu senden. Der I/O-Thread des Slave-Servers liest den vom Master-Server gesendeten Binlog-Dump-Thread und kopiert die Daten in eine lokale Datei im Slave Serverdatenverzeichnis, also das Relay-Protokoll. Der dritte Thread ist der SQL-Thread, um das Relay-Protokoll zu lesen und die im Protokoll enthaltenen Aktualisierungen auszuführen Der Slave-Server. Informationen.
Das Standard-Relay-Protokoll verwendet einen Dateinamen der Form host_name-relay-bin.nnnnnn, wobei host_name der Hostname des Slave-Servers und nnnnnn die Sequenznummer ist mit 000001. Verfolgen Sie die Relay-Log-Indexdatei, um das aktuell verwendete Relay-Log zu identifizieren. Standardmäßig werden diese Dateien im Datenverzeichnis des Slave-Servers erstellt hat das gleiche Format wie das Binärprotokoll und kann mit mysqlbinlog gelesen werden. Wenn der SQL-Thread alle Ereignisse im Relay-Log ausgeführt hat, wird das Relay-Log automatisch
vom Server gelöscht und im Datenverzeichnis werden zwei zusätzliche Statusdateien erstellt
.--master.info und Relay-log.info Statusdateien werden auf der Festplatte gespeichert und gehen beim nächsten Herunterfahren des Slave-Servers nicht verloren, um festzustellen, wie viele Binärdateien vorhanden sind Es hat vom Master-Server gelesen und inwieweit sie ihre eigenen Relay-Protokolle verarbeiten.
So richten Sie die Master-Slave-Replikation ein:
1. Stellen Sie sicher, dass die auf dem Master-Server und dem Slave-Server installierte MySQL-Version identisch ist. und vorzugsweise die neueste stabile Version von MySQL
auf dem Master-Server. Diesem Konto muss die REPLICATION-SLAVE-Berechtigung erteilt werden. Wenn das Konto nur für die Replikation verwendet wird, müssen keine weiteren Berechtigungen erteilt
werden GRANT REPLICATION SLAVE ON *.*
-> TO 'replication'. @'%.yourdomain.com' IDENTIFIED BY 'slavepass';
3. Führen Sie die FLUSH TABLES WITH READ LOCK-Anweisung aus, um alle Tabellen zu löschen und Schreibanweisungen zu blockieren:
mysql> FLUSH TABELLEN MIT LESESPERRE;
verhindern, dass das MySQL-Client-Programm beendet wird. Ein Terminal erstellt einen Snapshot des Hauptserver-Datenverzeichnisses.
Shell> cd /usr/local/mysql/
Shell> tar -cvf /tmp/mysql-snapshot.tar ./data
Wenn sich das Benutzerkonto des Slave-Servers von dem des Master-Servers unterscheidet, möchten Sie es möglicherweise nicht kopieren MySQL-Datenbank. In diesem Fall sollte die Datenbank aus dem Archiv ausgeschlossen werden. Sie müssen auch keine Protokolldateien oder Dateien „master.info“ oder „relay-log.info“ in das Archiv aufnehmen.
Wenn die durch FLUSH TABLES WITH READ LOCK festgelegte Lesesperre gültig ist (d. h. das MySQL-Client-Programm wird nicht beendet), lesen Sie den aktuellen Binärprotokollnamen und den Offsetwert auf dem Hauptserver:
mysql > SHOW MASTER STATUS
+--- --- ---------+----------+--------------+----------- -----+
|. Binlog_Do_DB |
. ------+----+
|
. mysql-bin.003 |.
--- -------+----------+--------------+------------- --- --+
In der Spalte „Datei“ wird der Protokollname und in „Position“ der Offset angezeigt. In diesem Beispiel ist der binäre Protokollwert mysql-bin.003 bei Offset 73. Notieren Sie diesen Wert. Diese Werte werden später beim Einrichten des Slave-Servers benötigt. Sie stellen die Replikationskoordinaten dar, von denen aus der Slave neue Aktualisierungen vom Master starten soll.
Wenn --logs-bin nicht aktiviert ist, während der Masterserver ausgeführt wird, sind die von SHOW MASTER STATUS angezeigten Protokollnamen- und Standortwerte leer. In diesem Fall sind die Werte, die beim Angeben der Protokolldatei und des Speicherorts des Slave-Servers in Zukunft verwendet werden müssen, leere Zeichenfolgen ('') und 4.
Nachdem Sie den Snapshot erstellt und den Protokollnamen und den Offset aufgezeichnet haben, kehren Sie zurück Zum vorherigen mittleren Ende zurückkehren und neu starten. Schreibaktivität aktivieren:
mysql> UNLOCK TABLES;
4. Stellen Sie sicher, dass der Abschnitt [mysqld] der Datei my.cnf auf dem Master-Server-Host eine Log-Bin-Option enthält. Dieser Abschnitt sollte auch über die Option server-id=Master_id verfügen, wobei master_id ein positiver ganzzahliger Wert zwischen 1 und 232–1 sein muss. Beispiel:
[mysqld]
log-bin
server-id=1
Wenn diese Optionen nicht bereitgestellt werden, sollten Sie sie hinzufügen und den Server neu starten.
5. Stoppen Sie den mysqld-Dienst auf dem Slave-Server und fügen Sie die folgende Zeile zu seiner my.cnf-Datei hinzu:
[mysqld]
server-id=2
Der Wert von „slave_id“ ist derselbe wie der Wert von „Master_id“ und muss eine positive Ganzzahl zwischen 1 und 232 sein –1. Wert. Außerdem muss sich die ID des Slave-Servers von der ID des Master-Servers unterscheiden.
6. Speichern Sie die Daten im Backup-Verzeichnis. Stellen Sie sicher, dass die Berechtigungen für diese Dateien und Verzeichnisse korrekt sind. Der Benutzer, unter dem MySQL läuft, muss wie auf dem Hauptserver Dateien lesen und schreiben können.
Shell> chown -R mysql:mysql /usr/local/mysql/data
7. Starten Sie den Slave-Server. Führen Sie die folgende Anweisung auf dem Slave-Server aus und ersetzen Sie dabei die Optionswerte durch die tatsächlichen Werte für Ihr System:
mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
- > MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
8. Starten Sie den Slave-Server-Thread:
mysql> START SLAVE;
Nach der Ausführung dieser Prozeduren sollte sich der Slave-Server mit dem Master-Server verbinden und alle ergänzen Aktualisierungen, die seit dem Snapshot stattgefunden haben.
9. Wenn ein Replikationsfehler auftritt, erscheint auch eine Fehlermeldung im Fehlerprotokoll (HOSTNAME.err) des Slave-Servers.
10. Beim Kopieren vom Server befinden sich die Dateien master.info und HOSTNAME-relay-log.info in dessen Datenverzeichnis. Der Slave verwendet diese beiden Dateien, um zu verfolgen, wie viel des Binärprotokolls des Masters verarbeitet wurde. Entfernen oder bearbeiten Sie diese Dateien nicht, es sei denn, Sie wissen genau, was Sie tun und verstehen ihre Bedeutung vollständig. Dennoch ist es besser, die CHANGE MASTER TO-Anweisung zu verwenden.