Detaillierte Erläuterung des Master-Slave-Replikationsprozesses in MySQL_Detaillierte Erläuterung von MySQL-Beispielen

Dieser Artikel stellt hauptsächlich den Implementierungsprozess der MySQL-Master-Slave-Replikation vor. Ich hoffe, er kann jedem helfen.

1. Was ist Master-Slave-Replikation?

Übertragen Sie die DDL- und DML-Vorgänge in der Master-Datenbank über Binärprotokolle (BINLOG) an die Slave-Datenbank und übertragen Sie sie dann Diese Protokolle werden erneut ausgeführt (Wiederholen). Dadurch werden die Daten in der Slave-Datenbank mit denen der Master-Datenbank 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ültigkeit gesetzt werden

4. Die Hauptdatenbank führt eine Datensicherung durch. Ich werde sie hier nicht vorstellen. Nach Abschluss der Sicherung kann die Hauptdatenbank aufgehoben werden Datenbank 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 Punkt sind konsistent.

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

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

8. Erstellen Sie eine Tabelle und 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 Schriftsatzes ist es zu hässlich, also habe ich es wie folgt organisiert:

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 wurden bereits erwähnt und sind 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 (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.

Verwandte Empfehlungen:

Detaillierte Erläuterung zum Einrichten einer Master-Slave-Instanz für die MySQL 5.7.18-Master-Slave-Replikation

Mycat Lese-Schreib-Trennung in MySQL Beispiele, die basierend auf der Master-Slave-Replikation implementiert wurden

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

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Master-Slave-Replikationsprozesses in MySQL_Detaillierte Erläuterung von MySQL-Beispielen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!