Detaillierte Erläuterung des MySQL Master-Slave-Replikationsprozesses

1. Was ist Master-Slave-Replikation?

Die DDL- und DML-Operationen in der Masterdatenbank werden über das Binärprotokoll (BINLOG) in die Slavedatenbank übertragen und diese Protokolle anschließend erneut ausgeführt (erneut erstellt). Auf diese Weise bleiben die Daten in der Slavedatenbank mit denen der Masterdatenbank konsistent.

2. Die Rolle der Master-Slave-Replikation

1. Wenn ein Problem mit der Masterdatenbank vorliegt, können Sie zur Slavedatenbank wechseln.

2. Es kann eine Lese- und Schreibtrennung auf Datenbankebene durchführen.

3. Die Slave-Datenbank kann täglich gesichert werden

3. Kopiervorgang

Binärprotokoll: Binärprotokoll der Hauptdatenbank

Relay-Log: Relay-Log vom Server

Schritt 1: Bevor jede Transaktion die Datenaktualisierung abschließt, schreibt der Master den Vorgangsdatensatz seriell in die Binlog-Datei.

Schritt 2: Der Server startet einen I/O-Thread, der eine normale Verbindung zum Master öffnet. Seine Hauptaufgabe ist der Binlog-Dump-Prozess. Wenn der Lesefortschritt den des Masters eingeholt hat, wechselt er in den Ruhemodus und wartet darauf, dass der Master neue Ereignisse generiert. Das ultimative Ziel 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 sequenziell aus, um die Konsistenz mit den Daten in der Hauptdatenbank zu wahren.

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

Ich habe zwei Instanzen von msyql in unterschiedlichen Pfaden im selben Windows installiert. Es wird empfohlen, dass die Installationsversionen von Master- und Slave-MySQL konsistent sind, meine sind jedoch inkonsistent.

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

Master

3306 ist die Standard-Portnummer von MySQL, die in der Masterinstanz nicht geändert werden muss. Mit „server-id“ wird eine eindeutige ID angegeben, die in verschiedenen MySQL-Instanzen nicht wiederholt werden sollte. „binlog-do-db“ gibt die zu kopierende Datenbank an. „log-bin“ wird zum Öffnen der binären Protokolldatei verwendet.

Salbe

Da die Master- und Slave-Datenbanken auf demselben Computer laufen, müssen die Ports unterschiedlich eingestellt werden, hier ist 3307

replicate-do-db: der Name der zu synchronisierenden Datenbank, der mit der Konfiguration auf dem Master übereinstimmen sollte.

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

Dieses neu hinzugefügte Konto kann in der Tabelle mysql.user abgefragt werden:

Als ich es zum ersten Mal bediente, schloss ich die Erstellung dieses Kontos hier ab, aber als ich es tatsächlich kopierte, stellte ich fest, dass das Kopieren nicht erfolgreich war. Als ich den Fehler überprüfte, stellte ich fest, dass das vom Master generierte Binlong in Ordnung war, und überprüfte dann den Status des Slaves:

Am Ende steht eine Fehlerzeile:

Es ist nicht möglich, über das Weidai-Konto eine Verbindung zum Master herzustellen. Daher wird das Binärprotokoll des Masters nicht abgerufen, was zur Folge hat, dass keine Relay-Protokolle generiert werden können.

Ich habe das Konto und das Passwort wiederholt überprüft, aber kein Problem gefunden. Dann habe ich nach relevanten Informationen gesucht und festgestellt, dass es daran lag, dass ich beim Erstellen eines neuen Benutzers im Master einen Schritt übersehen hatte:

Nachdem Sie einen neuen Benutzer eingerichtet oder das Kennwort geändert haben, müssen Sie Flush-Berechtigungen verwenden, um die Tabellen mit den MySQL-Systemberechtigungen zu aktualisieren. Andernfalls wird der Zugriff verweigert. Dies ist der Grund für den vorherigen Fehler. Eine andere Möglichkeit besteht darin, den MySQL-Server neu zu starten, damit die neuen Einstellungen wirksam werden.

3. Rufen Sie die aktuelle Datenposition in der Masterdatenbank ab. Dies wird hauptsächlich verwendet, um die Startposition der Daten nach dem Start der Slave-Daten zu kopieren. Bevor dieser Statuswert abgerufen wird, kann die Masterdatenbank die Daten jedoch nicht ändern. Daher müssen Sie zuerst die Lesesperre so einstellen, dass sie gültig ist.

4. Die Hauptdatenbank führt eine Datensicherung durch. Es gibt viele Möglichkeiten, Daten zu sichern. Ich werde sie hier nicht vorstellen. Sie können auf meinen vorherigen Artikel verweisen. Nachdem die Sicherung abgeschlossen ist, kann die Lesesperre aufgehoben werden und die Hauptdatenbank kann Schreibvorgänge durchführen.

5. Starten Sie die Slave-Datenbank und stellen Sie die gerade gesicherten Daten wieder her. Zu diesem Zeitpunkt sind die Daten in der Master- und Slave-Datenbank zum Zeitpunkt der Sicherung konsistent.

6. Verwandte Konfiguration des Replikationsverhaltens auf der Slave-Datenbank

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

8. Erstellen Sie eine Tabelle und fügen Sie im Master neue Daten hinzu. Beachten Sie im Slave:

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

5. Interpretation des Master-Slave-Synchronisationsstatus

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

Da das Layout zu hässlich ist, habe ich es folgendermaßen sortiert:

Slave_IO_STATE: Wartet darauf, dass der Master ein Ereignis sendet

Master_host:127.0.0.1

Master_Benutzer: weidai

Master_port:3306

connect_retry:60

Master_log_file:mysql-bin.000005

Read_Master_log_pos:1662

Relay-Logdatei:AE6Z*****-relay-bin.000002

Relay_log_pos:1415

Slave_IO_Running: ja

Slave_SQL_Running: ja

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

Slave_IO_Running: ja

Slave_SQL_Running: ja

Wie bereits erwähnt, sind diese beiden Threads zwei sehr wichtige Threads, die am Replikationsprozess auf dem Slave beteiligt sind. JA bedeutet normal, NEIN bedeutet abnormal.

Der Slave_IO-Thread kopiert hauptsächlich den Binlong-Protokollinhalt auf dem Master in das Relay-Protokoll (Relay_log) des Slaves. Im Allgemeinen ist die Wahrscheinlichkeit von Problemen nicht hoch. Die meisten Probleme werden durch Berechtigungs- oder Netzwerkprobleme verursacht, die dazu führen, dass keine Verbindung zum Master hergestellt werden kann. Genau wie der oben erwähnte Fehler.

Der Slave_SQL-Thread ist für die Ausführung des SQL im Relay-Protokoll verantwortlich und weist eine relativ höhere Fehlerwahrscheinlichkeit auf. Wenn beispielsweise jemand manuell einige Datensätze in die Slave-Datenbank einfügt, kann während der Master-Slave-Synchronisierung ein Primärschlüsselkonflikt auftreten.

Slave_IO_STATE: Wartet darauf, dass der Master ein Ereignis sendet

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

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.