MySQL Master-Slave-Synchronisationsmechanismus und Tracking-Prozess für Synchronisationsverzögerungsprobleme

Vorwort

Als DBA werden Sie bei Ihrer Arbeit häufig auf Verzögerungen bei der MySQL-Master-Slave-Synchronisierung stoßen. Diese langsamen Synchronisierungsprobleme haben tatsächlich viele Ursachen. Sie können durch Netzwerkprobleme zwischen Master und Slave, Probleme mit der Netzwerkbandbreite, große Transaktionen oder Verzögerungen durch Single-Thread-Replikation verursacht werden.

Ich bin heute auf ein Problem gestoßen. Mysql meldete ständig Fehler und die Verzögerung bei der Master-Slave-Synchronisierung war zu groß oder falsch. In diesem Artikel erfahren Sie mehr über das Mechanismusprinzip der Master-Slave-Synchronisierung sowie Ideen zur Fehlerbehebung.

Fehlermanifestation

Die intuitivste Leistung ist:

mysql> Slave-Status anzeigen\G;
 // Status 1 Seconds_Behind_Master: NULL
 // Status 2 Sekunden_Hinter_Master: 0
 // Status 3 Sekunden_Hinter_Master: 79

Bei kontinuierlichen Abfragen ist der Attributwert meistens 0 und gelegentlich erscheint ein verzögerter Wert wie Null oder 79. Dies führt dazu, dass die Überwachung der Master-Slave-Synchronisierungsverzögerung weiterhin Alarm gibt.

Ursachen und Lösungen

Die Server-IDs mehrerer Backup-Server sind gleich, was dazu führt, dass der Host über längere Zeit keine Verbindung zu einem Backup-Server herstellen kann und somit nicht normal synchronisiert werden kann.

Starten Sie die Datenbank nach der Änderung der Server-ID neu, um sie wiederherzustellen.

Master-Slave-Synchronisationsmechanismus

Die MySQL Master-Slave-Synchronisierung, auch Replikation genannt, ist eine integrierte Clusterlösung mit hoher Verfügbarkeit und Leistung mit den folgenden Hauptfunktionen:

• Datenverteilung: Die Synchronisierung erfordert keine große Bandbreite und kann Daten in mehreren Rechenzentren replizieren.
• Leselastausgleich: Durch Servercluster können Sie GSLB-Methoden (Global Load Balancing) wie DNS-Polling und Linux LVS verwenden, um den Lesedruck auf dem Hauptserver zu reduzieren.
• Datenbanksicherung: Die Replikation ist Teil der Sicherung, aber kein Ersatz dafür. Es muss auch mit Schnappschüssen kombiniert werden.
• Hohe Verfügbarkeit und Failover: Der Slave-Server kann schnell zum Master-Server wechseln, wodurch Ausfallzeiten und Wiederherstellungszeiten reduziert werden.

Die Master-Slave-Synchronisation gliedert sich in 3 Schritte:

1. Der Masterserver (Master) protokolliert Datenänderungen im Binärprotokoll (Binlog).
2. Der Slave-Server kopiert das Binärprotokoll des Master-Servers in sein eigenes Relay-Protokoll.
3. Führen Sie die Protokollierung im Relay-Log des Servers erneut durch und übernehmen Sie die Änderungen in Ihre eigene Datenbank um Datenkonsistenz zu erreichen.

Bei der Master-Slave-Synchronisation handelt es sich um eine asynchrone Echtzeitsynchronisation, bei der zwar in Echtzeit übertragen wird, es jedoch zu einer Verzögerung bei der Ausführung kommt. Wenn der Master-Server stark ausgelastet ist, erhöht sich die Verzögerung entsprechend.

Aus der obigen Abbildung können Sie erkennen, dass insgesamt 3 Threads erforderlich sind:

1. Der Protokollübertragungsthread des primären Servers: verantwortlich für die Übertragung binärer Protokollinkremente an den Standby-Server
2. Der E/A-Thread des Slave-Servers: verantwortlich für das Lesen des Binärprotokolls des Master-Servers und dessen Speicherung als Relay-Protokoll
3. Der SQL-Thread des Slave-Servers ist für die Ausführung des Relay-Logs verantwortlich.

MySQL-Threads anzeigen

Wir können show full processlist; “ verwenden, um den Status von MySQL anzuzeigen:

Status des Hosts:

Status der Standby-Maschine:

Wie Sie sehen, besteht meine Clusterarchitektur aus 1 Host und 4 Standby-Maschinen, sodass es im Host 4 Synchronisierungsthreads gibt (alle Binlog-Daten wurden an die Standby-Maschine gesendet und warten auf Binlog-Protokollaktualisierungen) und 1 Anzeigebefehlsthread (vollständige Prozessliste anzeigen). Auf der Standby-Maschine gibt es 1 Anzeigebefehls-Thread, 1 E/A-Thread (der darauf wartet, dass der Master Synchronisierungsdatenereignisse sendet) und 1 SQL-Thread (der alle Relay-Protokolle gelesen hat und darauf wartet, dass der E/A-Thread ihn aktualisiert).

Synchronisierungsstatus anzeigen

Da die Master-Slave-Synchronisierung asynchron und in Echtzeit erfolgt, kommt es zu Verzögerungen. Wir können show slave status; verwenden, um die Synchronisierungsverzögerung auf dem Standby-Rechner anzuzeigen:

Einige Eigenschaften, auf die wir bei der Master-Slave-Synchronisation achten müssen, haben wir rot markiert:

• Slave_IO_State: Der Status des aktuellen I/O-Threads
• Master_Log_File: Die Binärdatei des aktuell synchronisierten Masterservers
• Read_Master_Log_Pos: Der Offset der Binärdatei des aktuell synchronisierten Masterservers in Bytes. Wie in der Abbildung gezeigt, wurden 12,9 M (13630580/1024/1024) synchronisiert.
• Relay_Master_Log_File: Binärdatei der aktuellen Relay-Log-Synchronisierung
• Slave_IO_Running: Der Ausführungsstatus des E/A-Threads im Slave-Server. JA bedeutet, dass er normal ausgeführt wird.
• Slave_SQL_Running: Der Ausführungsstatus des SQL-Threads im Slave-Server. JA bedeutet, dass er normal ausgeführt wird.
• Exec_Master_Log_Pos: Gibt den Binärprotokoll-Offset des Masterservers an, bei dem die Synchronisierung abgeschlossen ist.
• Seconds_Behind_Master: Gibt die Dauer an, um die die Daten des Slave-Servers hinter denen des Master-Servers zurückbleiben.

Sie können auch den Befehl „show master status;“ verwenden, um den Laufstatus des Masterservers anzuzeigen:

Normaler Master-Slave-Synchronisierungsstatus:

Slave_IO_Running: JA
Slave_SQL_Running: JA
Sekunden_Hinter_Master: 0

Fehlerbehebung

Nachdem wir den Master-Slave-Synchronisationsmechanismus verstanden haben, schauen wir uns das Problem an, auf das wir heute gestoßen sind. Indem wir den Status der Standby-Maschine überprüfen, beobachten wir mehrere Schlüsselattributwerte in drei Zuständen:

mysql> Slave-Status anzeigen\G;
#Zustand 1:
 Slave_IO_State: Wiederverbindung nach fehlgeschlagenem Lesen des Master-Ereignisses
 Slave_IO_Running: Nein
 Slave_SQL_Running: Ja
 Seconds_Behind_Master: NULL
#Zustand 2:
 Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
 Slave_IO_Running: Ja
 Slave_SQL_Running: Ja
 Sekunden_Hinter_Master: 0
#Staat drei:
 Slave_IO_State: Master-Ereignis in die Relay-Log-Warteschlange einreihen
 Slave_IO_Running: Ja
 Slave_SQL_Running: Ja
 Sekunden_Hinter_Master: 636

Durch den Statusübergang des MySQL-Master-Slave-Replikationsthreads können wir die unterschiedlichen Bedeutungen der drei Status erkennen:

# Status 1# 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“.
Wiederherstellen der Verbindung nach einem fehlgeschlagenen Lesen des Master-Ereignisses
# Status 2# 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.
Warten auf das Senden des Ereignisses durch den Master

# Zustand drei # Der Thread hat ein Ereignis gelesen und kopiert es in das Relay-Protokoll, damit es vom SQL-Thread verarbeitet werden kann.
Einreihen des Master-Ereignisses in das Relay-Protokoll

Hier können wir vermuten, dass der Slave-Server aus irgendeinem Grund immer wieder die Verbindung zum Master-Server trennt und versucht, die Verbindung wiederherzustellen, und die Verbindung dann nach erfolgreicher Wiederherstellung erneut trennt.

Werfen wir einen Blick auf die Funktionsweise des Hosts:

Wir haben festgestellt, dass das Problem auf zwei Rechnern auftrat, 10.144.63.* und 10.144.68.*. Wir haben das Fehlerprotokoll eines davon überprüft:

190214 11:33:20 [Anmerkung] Slave: Endpaket vom Server empfangen, offensichtliches Herunterfahren des Masters:
190214 11:33:20 [Hinweis] Slave-E/A-Thread: Fehler beim Lesen des Protokollereignisses. Erneutes Verbinden zum erneuten Versuch, Protokoll „mysql-bin.005682“ an Position 13628070

Nach einer Google-Suche nach dem Stichwort „Slave: received end packet from server, apparent master shutdown:“ erfährt man im Artikel „Confusing MySQL Replication Error Message“, dass die Ursache darin liegt, dass die Server-IDs der beiden Standby-Server dupliziert sind.

Eines Tages ist es mir passiert und ich habe fast eine Stunde gebraucht, um das herauszufinden.
Von nun an verwende ich immer eine my.cnf-Basisdatei, die ich auf einen anderen Server kopiere, und als Erstes erhöhe ich die Server-ID.
Könnte MySQL einfach den Servernamen anstelle eines numerischen Werts verwenden?

Fehlerbehebungen

Nachdem wir das Problem lokalisiert hatten, überprüften wir, ob eine Duplizierung vorlag, und stellten fest, dass die Felder auf den beiden Sicherungsmaschinen tatsächlich identisch waren:

vim meine.cnf

#Replikation
log-bin=mysql-bin
# Diese Zufallszahl ist dieselbe wie Server-ID=177230069
sync_binlog=1

Ändern Sie eine andere Nummer, speichern Sie, starten Sie den MySQL-Prozess neu und der Alarm wird wiederhergestellt.

Zusammenfassen

Letztendlich ist die Lösung für dieses Problem sehr einfach, aber der Wechsel von anfänglicher Verwirrung zu klaren Ideen am Ende ist bei der Fehlerbehebung üblich. Der Hauptnutzen dieses Artikels besteht darin, dass er Ihnen den Mechanismus der Master-Slave-Synchronisierung und die Ideen zur Problemverfolgung näherbringt. Ich hoffe, dass wir die Probleme, die uns durch die Master-Slave-Synchronisierung entstehen, beim nächsten Mal schnell lösen können.

Nun, 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.

Verweise

• "MySQL-Grundlagen: InnoDB Storage Engine 2. Auflage" P8.7 Kopie
• MySQL Master-Slave Replikationsthread-Statusänderung
• Verwirrende MySQL-Replikationsfehlermeldung