Detailliertes Beispiel dafür, wie MySQL den Master-Slave-Replikationsprozess implementiert (Bild)

In diesem Artikel wird hauptsächlich der Implementierungsprozess der MySQL-Master-Slave-Replikation im Detail vorgestellt, der einen gewissen Referenzwert hat.

1. Was ist Master-Slave-Replikation?

überträgt DDL- und DML-Vorgänge in der Master-Datenbank über Binärprotokolle (BINLOG) und führt diese Protokolle dann erneut aus (wiederholen), wodurch die Daten in der Slave-Datenbank mit denen des Masters konsistent werden Datenbank Die Datenbank bleibt konsistent.

2. Die Rolle der Master-Slave-Replikation

1. Wenn es ein Problem mit der Master-Datenbank gibt, können Sie zur Slave-Datenbank wechseln.

2. Lese- und Schreibtrennung kann auf Datenbankebene durchgeführt werden

3. Tägliches Backup kann auf der Slave-Datenbank durchgeführt werden

3

Binärprotokoll: Binärprotokoll der Master-Datenbank

Relay-Protokoll: Relay-Protokoll des Slave-Servers

Nr. Schritt: Der Master schreibt den Vorgangsdatensatz seriell in die Binlog-Datei, bevor die Aktualisierungsdaten jeder Transaktion abgeschlossen sind.

Schritt 2: salve öffnet einen I/O-Thread. Dieser Thread öffnet eine normale Verbindung auf dem Master und seine Hauptaufgabe ist der Binlog-Dump-Prozess. Wenn der Lesefortschritt den Master eingeholt hat, wechselt er in den Ruhezustand und wartet darauf, dass der Master neue Ereignisse generiert. Der ultimative Zweck des E/A-Threads besteht darin, diese Ereignisse in das Relay-Protokoll zu schreiben.

Schritt 3: SQL Thread liest das Relay-Protokoll und führt die SQL-Ereignisse im Protokoll nacheinander aus, um eine Konsistenz mit den Daten in der Hauptdatenbank zu gewährleisten.

4. Spezifische Vorgänge der Master-Slave-Replikation

Ich habe zwei msyql-Instanzen in unterschiedlichen Pfaden in denselben Fenstern installiert. Es wird empfohlen, dass die hier zwischen Master und Slave installierten MySQL-Versionen konsistent sind, obwohl meine eigene inkonsistent ist.

1. Ändern Sie die Konfigurationsdatei my.ini der Master- und Slave-Datenbanken.

Master

3306 ist die Standard-Portnummer von MySQL, die in der Master-Instanz nicht geändert werden muss; die Server-ID wird zur Angabe einer eindeutigen ID verwendet, andere MySQL-Instanzen tun dies nicht muss wiederholt werden; binlog-do-db gibt an, dass die Datenbank kopiert werden muss; log-bin wird zum Öffnen binärer Protokolldateien verwendet.

salve

Da die Master-Slave-Datenbank später auf demselben Computer läuft, muss der Port auf einen anderen eingestellt werden Dasselbe, hier ist 3307

replicate-do-db: der Name der Datenbank, die synchronisiert werden muss, konsistent mit der Konfiguration auf dem Master.

2. Erstellen Sie ein Konto speziell für die Replikation auf dem Master: weidai/123456

Dieses neue Konto finden Sie in der Tabelle mysql.user Erstellen Sie ein Abfrage:

Als ich den ersten Vorgang durchführte, habe ich die Erstellung dieses Kontos hier abgeschlossen, aber als ich es tatsächlich kopierte, stellte ich fest, dass keine Kopie vorhanden war . Bei der Fehlerbehebung haben wir festgestellt, dass kein Problem mit dem vom Master generierten Binlong vorliegt, und haben dann den Status des Slaves überprüft:

Am Ende steht eine solche Fehlerzeile:

Sie können mit dem Weidai-Konto keine Verbindung zum Master herstellen, daher sollte das Binlog des Masters nicht abgerufen werden, was dazu führt Relay-Protokoll wird nicht generiert.

Ich habe das Konto und das Passwort wiederholt überprüft und keine Probleme gefunden. Dann habe ich nach relevanten Informationen gesucht und herausgefunden, dass es daran lag, dass beim Erstellen eines neuen Benutzers durch den Master ein Schritt fehlte:

Richten Sie einen neuen Benutzer ein oder ändern Sie ihn. Nach der Eingabe des Passworts müssen Sie Flush-Berechtigungen verwenden, um die Systemberechtigungstabellen von MySQL zu aktualisieren, andernfalls wird der Zugriff verweigert. Aus diesem Grund ist der vorherige Fehler aufgetreten. Eine andere Möglichkeit besteht darin, den MySQL-Server neu zu starten, damit die neuen Einstellungen wirksam werden.

3. Ermitteln Sie zu diesem Zeitpunkt die Position der Daten in der Hauptdatenbank. Dies wird jedoch hauptsächlich zum Kopieren der Startposition der Daten verwendet Bevor dieser Statuswert abgerufen wird, kann die Hauptdatenbank keine Datenänderungsvorgänge mehr ausführen. Daher muss zuerst die Lesesperre auf gültig gesetzt werden

4. Die Hauptdatenbank führt eine Datensicherung durch. Ich werde sie hier nicht vorstellen. Nach Abschluss der Sicherung kann die Lesesperre aufgehoben werden kann Schreibvorgänge ausführen

5. Starten Sie die Slave-Datenbank und stellen Sie die Daten der Master- und Slave-Datenbanken zum Zeitpunkt der Sicherung wieder her sind konsistent.

6. Konfiguration im Zusammenhang mit dem Replikationsverhalten auf der Slave-Datenbank

7. Zu diesem Zeitpunkt ist die Konfiguration abgeschlossen, die Slave-Datenbank kann jedoch noch nicht abgeschlossen werden synchronisiert und muss gestartet werden Slave-Thread

8. Erstellen Sie eine Tabelle, fügen Sie Daten im Master hinzu und beobachten Sie sie im Slave:

Ja Es ist ersichtlich, dass die Operationen, die ich im Master ausführe, im Slave widergespiegelt werden können. Zu diesem Zeitpunkt ist der Slave wie ein Spiegel des Masters.

5. Interpretation des Master-Slave-Synchronisationsstatus

Verwenden Sie den Befehl auf dem Slave, um Folgendes anzuzeigen:

Aufgrund des Satzes ist es zu hässlich, also habe ich es wie folgt geklärt:

Slave_IO_STATE:Waiting for master to send event
Master_host:127.0.0.1
Master_user:weidai
Master_port:3306
connnect_retry:60
Master_log_file:mysql-bin.000005
Read_Master_log_pos:1662
Relay_log_file:AE6Z*****-relay-bin.000002
Relay_log_pos:1415
Slave_IO_Running:yes
Slave_SQL_Running:yes

----------------------- ---------- -----------Wunderschöne Trennlinie----------- -------------- ---------

Slave_IO_Running:yes

Slave_SQL_Running:yes

Diese beiden Threads Wie bereits erwähnt, handelt es sich um zwei sehr wichtige Threads auf dem Slave, die am Replikationsprozess teilnehmen. JA bedeutet normal, NEIN bedeutet abnormal.

Der Slave_IO-Thread kopiert hauptsächlich den Binlong-Protokollinhalt in das Relay-Protokoll des Slaves (Relay_log). Die meisten Probleme werden durch Berechtigungen oder Netzwerkprobleme verursacht Master. Genau wie der zuvor erwähnte Fehler.

Der Slave_SQL-Thread ist für die Ausführung der SQL im Relay-Protokoll verantwortlich und die Fehlerwahrscheinlichkeit ist relativ hoch. Wenn jemand einige Datensätze manuell in die Slave-Datenbank einfügt, kommt es während der Master-Slave-Synchronisierung zu einem Primärschlüsselkonflikt.

Slave_IO_STATE: Warten auf das Senden eines Ereignisses durch den Master

Dieser Status zeigt an, dass die Synchronisierung des Relay-Protokolls abgeschlossen ist und auf die Generierung neuer Ereignisse durch den Master gewartet wird.

Das obige ist der detaillierte Inhalt vonDetailliertes Beispiel dafür, wie MySQL den Master-Slave-Replikationsprozess implementiert (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!