Tiefgreifendes Verständnis des Statusübergangs des MySQL-Master-Slave-Replikationsthreads

Vorwort

Das Grundprinzip der MySQL-Master-Slave-Replikation besteht darin, dass die Slave-Datenbank eine Verbindung zur Master-Datenbank herstellt und die Master-Datenbank einen DUMP-Thread für die Master-Datenbank generiert. Die Hauptaufgabe des DUMP-Threads besteht darin, Binlog-Protokolle zu minen und sie dann an den IO-Thread der Slave-Datenbank zu senden. Nach dem Empfang des Protokollstroms schreibt der IO-Thread ihn in das Relay-Protokoll. Ein anderer Thread, der SQL-Thread, liest den Inhalt des Relay-Protokolls und gibt dann die SQL-Anweisung erneut wieder.

Dieser Artikel stellt hauptsächlich den relevanten Inhalt zum Statusübergang des MySQL-Master-Slave-Replikationsthreads vor. Werfen wir einen Blick auf die ausführliche Einführung.

1. Thread-Statuswert der Hauptbibliothek

Die folgende Liste zeigt die häufigsten Status, die Sie in der Spalte „State“ des Binlog-Dump-Threads eines Masterservers bei der Master-Slave-Replikation sehen können ( SHOW PROCESSLIST ). Wenn der Binlog-Dump-Thread auf dem Masterserver nicht angezeigt wird, bedeutet dies, dass die Replikation nicht ausgeführt wird, d. h., dass derzeit keine Slave-Hosts verbunden sind.

Senden eines Binlog-Ereignisses an den Slave

Das Binärprotokoll besteht aus verschiedenen Ereignissen, wobei ein Ereignis normalerweise ein Update plus einige andere Informationen ist. Der Thread hat ein Ereignis aus dem Binärprotokoll gelesen und sendet es an den Slave.

Ein Binärprotokoll ist fertig gelesen; zum nächsten Binärprotokoll wechseln

Der Thread hat das Lesen der Binärprotokolldatei abgeschlossen und öffnet die nächste Protokolldatei zum Senden an den Slave-Server.

Hat das gesamte Binärprotokoll an den Slave gesendet; wartet auf die Aktualisierung des Binärprotokolls

Der Thread hat alle wichtigen Updates aus dem Binärprotokoll gelesen und an den Slave-Server gesendet. Der Thread ist nun im Leerlauf und wartet darauf, dass im Binärprotokoll neue Ereignisse angezeigt werden, die aus neuen Updates auf dem Master resultieren.

Warten auf die endgültige Kündigung

Ein sehr einfacher Zustand, der auftritt, wenn ein Thread gestoppt wird.

2. Slave-E/A-Thread-Statuswert

Verbindung zum Master herstellen

Der Thread versucht, eine Verbindung zum primären Server herzustellen.

Masterversion prüfen

Ein temporärer Zustand, der unmittelbar nach der Herstellung einer Verbindung mit dem primären Server eintritt.

Slave beim Master registrieren

Ein temporärer Zustand, der unmittelbar nach der Herstellung einer Verbindung mit dem primären Server eintritt.

Binlog-Dump anfordern

Ein temporärer Zustand, der unmittelbar nach der Herstellung einer Verbindung mit dem primären Server eintritt. Der Thread sendet eine Anforderung des Inhalts des Binärprotokolls an den Masterserver, beginnend mit dem angeforderten Namen und der Position der Binärprotokolldatei.

Warten auf erneute Verbindung nach einer fehlgeschlagenen Binlog-Dump-Anforderung

Wenn die Anforderung zum Erstellen eines Binärprotokoll-Dumps fehlschlägt (aufgrund fehlender Verbindung), wird der Thread in den Ruhezustand versetzt und versucht dann in regelmäßigen Abständen, die Verbindung wiederherzustellen. Das Intervall zwischen den Wiederholungsversuchen kann mit der Option --master-connect-retry angegeben werden.

Erneutes Verbinden nach einer fehlgeschlagenen Binlog-Dump-Anforderung

Der Thread versucht, die Verbindung zum primären Server wiederherzustellen.

Warten auf das Senden des Ereignisses durch den Master

Der Thread hat eine Verbindung zum primären Server hergestellt und wartet auf das Eintreffen binärer Protokollereignisse. Wenn der primäre Server im Leerlauf ist, kann es länger dauern. Wenn die Wartezeit länger als slave_read_timeout Sekunden ist, tritt ein Timeout auf. An diesem Punkt betrachtet der Thread die Verbindung als unterbrochen und versucht, die Verbindung wiederherzustellen.

Einreihen des Master-Ereignisses in das Relay-Protokoll

Der Thread hat ein Ereignis gelesen und kopiert es zur Verarbeitung durch den SQL-Thread in das Relay-Protokoll.

Warten auf erneute Verbindung nach einem fehlgeschlagenen Lesen des Master-Ereignisses

Wenn beim Lesen ein Fehler auftritt (aufgrund fehlender Verbindung), schläft der Thread für die Dauer von „Master-Connect-Retry“ (Sekunden) und versucht dann, die Verbindung wiederherzustellen.

Wiederherstellen der Verbindung nach einem fehlgeschlagenen Lesen des Master-Ereignisses

Der Thread versucht, die Verbindung zum Masterserver wiederherzustellen. Wenn die Verbindung wiederhergestellt ist, ändert sich der Status in „Warten auf Senden des Ereignisses durch den Master“.

Warten, bis der Slave-SQL-Thread genügend Relay-Log-Speicherplatz freigibt

Es wird ein von Null verschiedener Wert für „relay_log_space_limit“ verwendet und die Relay-Protokolle sind so groß geworden, dass ihre Gesamtgröße diesen Wert überschreitet. Der E/A-Thread wartet, bis der SQL-Thread den Inhalt des Relay-Protokolls verarbeitet und einige Relay-Protokolldateien löscht, um genügend Speicherplatz freizugeben.

Warten auf Slave-Mutex beim Beenden

Ein sehr einfacher Zustand, der auftritt, wenn ein Thread gestoppt wird.

3. Slave-SQL-Thread-Statuswert

Ereignis aus dem Relay-Log lesen

Der Thread hat ein Ereignis aus dem Relay-Protokoll gelesen und kann das Ereignis verarbeiten.

Hat das gesamte Relay-Protokoll gelesen; wartet auf die Aktualisierung durch den Slave-E/A-Thread

Der Thread hat alle Ereignisse in der Relay-Protokolldatei verarbeitet und wartet nun darauf, dass der E/A-Thread neue Ereignisse in das Relay-Protokoll schreibt.

Warten auf Slave-Mutex beim Beenden

Ein sehr einfacher Zustand, der auftritt, wenn ein Thread gestoppt wird.

4. Statuswert des Slave-Verbindungsthreads

Diese Thread-Zustände treten auf Replikations-Slaves auf, sind jedoch mit dem Verbindungs-Thread verknüpft, nicht mit dem E/A- oder SQL-Thread.

Master ändern

Der Thread verarbeitet eine CHANGE MASTER TO-Anweisung.

Sklave töten

Der Thread verarbeitet eine STOP SLAVE-Anweisung.

Öffnen der Master-Dump-Tabelle

Dieser Zustand tritt nach dem Erstellen der Tabelle aus dem Master-Dump auf.

Daten der Master-Dump-Tabelle werden gelesen

Dieser Zustand tritt nach dem Öffnen der Master-Dump-Tabelle auf.

Neuerstellen des Indexes in der Master-Dump-Tabelle

Dieser Zustand tritt nach dem Lesen der Daten der Master-Dump-Tabelle ein.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.