In einer MySQL-Hosting-Replikationseinrichtung wird der Parameter Seconds_Behind_Master (SBM), wie er vom Befehl SHOW SLAVE STATUS angezeigt wird, häufig als Hinweis auf die aktuelle Replikationsverzögerung des Slaves verwendet . In diesem Blogbeitrag untersuchen wir, wie dieser Wert in verschiedenen Situationen zu verstehen und zu interpretieren ist.
Mögliche Werte von Sekunden hinter dem Meister
Der Wert von SBM, wie in der MySQL-Dokumentation erläutert, hängt im Allgemeinen vom Status des MySQL-Slaves und insbesondere vom Status des MySQL-Slaves SQL_THREAD und IO_THREAD ab. Während sich IO_THREAD mit dem Master verbindet und die Aktualisierungen liest, wendet SQL_THREAD diese Aktualisierungen auf dem Slave an. Lassen Sie uns die möglichen Werte von SBM während verschiedener Zustände des MySQL-Slaves untersuchen.
Wenn der SBM-Wert Null ist
- SBM ist immer NULL, wenn Ihr Slave gestoppt ist oder Ihr SQL-Thread gestoppt ist (oder nicht läuft).
- SBM ist auch NULL, wenn der IO-Thread gestoppt wird, vorausgesetzt, der SQL-Thread hat bereits alle Ereignisse aus dem Relay-Log verarbeitet. Eine Beispielausgabe von SHOW SLAVE STATUS (getrimmt, um nur relevante Werte anzuzeigen) demonstriert dies:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nein
Slave_SQL_Running:Ja
Sekunden_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave hat das gesamte Relay-Log gelesen; Warten auf weitere Updates
Abgerufener_Gtid_Satz:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Ausgeführter_Gtid_Satz:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Wenn der SBM-Wert null oder positiv ist
- SBM gibt einen gültigen Wert (>=0) wieder, wenn der SQL-Thread aktiv Ereignisse verarbeitet. Dies gilt unabhängig vom Status des IO-Threads. Zum Beispiel:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nein
Slave_SQL_Running:Ja
Sekunden_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Warten auf Slave-Worker, um ihre Warteschlangen zu verarbeiten
Abgerufener_Gtid_Satz:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Ausgeführter_Gtid_Satz:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Im obigen Beispiel können wir sehen, dass der Slave hinter dem Master ist, indem wir das Retrieved_GTID_Set und das Executed_GTID_Set vergleichen. In solchen Fällen repräsentiert Seconds_Behind_Master die Differenz zwischen dem Zeitstempel der letzten vom SQL-Thread verarbeiteten Transaktion und dem Zeitstempel derselben Transaktion, als sie auf dem Master verarbeitet wurde. Dieser Transaktionszeitstempel des Masters wird durch die Replikation bewahrt und daher kann der Slave den SBM lokal berechnen.
Sobald der Slave alle Relay-Protokolle vollständig eingeholt hat (d. h. die ausgeführte GTID wird zu 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), wird Seconds_Behind_Master auf '0' setzen, wenn der IO-Thread läuft, oder auf 'NULL', wenn der IO-Thread nicht läuft.
#MySQL-Tutorial – Die Sekunden hinter dem Masterwert verstehenClick To Tweet
Verständnis der Ausführungsgeschwindigkeit des MySQL-Slaves
Unter der Annahme, dass sich der SQL-Thread und der IO-Thread auf dem Slave im laufenden Zustand befinden, ist es möglich, die relativen Ausführungsgeschwindigkeiten des Masters und des Slaves zu verstehen, indem der SBM-Wert überwacht wird. Ein konsistenter „0“-Wert oder ein konstanter Wert zeigt an, dass der Slave mit der gleichen Geschwindigkeit wie der Master ausgeführt wird. Andererseits zeigt eine ansteigende Steigung für Seconds_Behind_Master an, dass der Slave langsamer arbeitet als der Master.
Die Überwachungskonsole von ScaleGrid für MySQL in Azure zeichnet die Werte von SBM im Zeitverlauf für die Slave-Knoten auf.
Null oder konstanter Wert von SBM
Im obigen Beispiel wurde der Slave etwa 40 Stunden nach aktiven Schreibvorgängen des Masters gestartet. Nach dem Start begann der Slave, diese Daten zu replizieren, und wir sehen, dass das SBM ziemlich flach war, was darauf hinweist, dass der Slave mit der gleichen Geschwindigkeit wie der Master ausgeführt wurde. Beachten Sie auch, dass der Abfall von SBM auf "0" steil ist, was wirklich bedeutet, dass, obwohl die letzte Transaktion, die der Slave ausgeführt hat, etwa 40 Stunden zuvor auf dem Master ausgeführt wurde, es nach dem Aufholen eine "0"-Verzögerung gibt.
Steigerung der SBM-Werte
In der Grafik unten können wir sehen, dass SBM ständig zunimmt, was bedeutet, dass die Ausführungsgeschwindigkeit des Slaves im Vergleich zu der des Masters geringer ist. Dies ist tatsächlich ein Fall, in dem wir 20 Threads ausführen, die kontinuierlich auf dem Master schreiben, und ein Single-Threaded-Slave kann damit nicht Schritt halten.
Zu guter Letzt ist es wichtig anzumerken, dass wir in unseren bisherigen Diskussionen nicht von Netzwerkengpässen ausgegangen sind. Bei langsamen Netzwerken hinkt der Slave-IO-Thread selbst dem Master hinterher, und wenn der SQL-Thread schnell genug ist, oszilliert der SBM zwischen „0“ und einer positiven Zahl. In solchen Fällen ist SBM kein nützlicher Parameter, um die tatsächliche Verzögerung mit dem Master zu verstehen.
Wenn Ihnen dieser Blogbeitrag gefallen hat, sehen Sie sich unsere anderen beliebten Tutorials zur Verwaltung von MySQL-Datenbanken an, um mehr über die Optimierung Ihrer Bereitstellungen zu erfahren:
- Berechnung der InnoDB-Pufferpoolgröße für Ihren MySQL-Server
- MySQL-Tutorial – Konfigurieren und Verwalten von SSL auf Ihrem MySQL-Server
- MySQL High Availability Framework erklärt – Teil I:Einführung
