Zeigt `Seconds_behind_master` die genaue Sklavenverzögerung vom Master auf?
-
16-10-2019 - |
Frage
Tut Seconds_Behind_Master
Zeigen Sie immer die richtige Anzahl von Sekunden an, die der Sklave hinter dem Meister steht?
Ich habe auch die Replikationsüberwachung von MK-Heartbeat implementiert.
Es wurde das andere Ergebnis im Vergleich mit Seconds_behind_master gezeigt.
Welches ist genauer?
Lösung
Seconds_Behind_Master basiert auf der Differenz zwischen UNIX_Timestamp () und dem Zeitstempel, der für die Abfrage innerhalb des Binärprotokolls des Meisters oder des Relaisprotokolls auf dem Sklaven angemeldet ist. Seconds_Behind_Master wird im Kontext der Echtzeit tatsächlich verloren, wenn Replikation eine Reihe von langlaufenden Abfragen verarbeitet. Die Verzögerung könnte astronomisch wachsen, bis alle Relais -Protokolleinträge verarbeitet werden und dann Seconds_behind_master plötzlich auf Null fallen. In Bezug auf die Echtzeit haben Sie keine Möglichkeit, zu wissen oder zu antizipieren, wann die Verzögerung Eventaully auflöst, bis sie Null erreicht.
Strikt mit MySQL können Sie die Replikationsverzögerung in Echtzeit auf folgende Weise überwachen:
- Aus
SHOW SLAVE STATUS\G
, Holen Sie sich zwei WerteRelay_Master_Log_File
Repräsentiert Protokolldatei, die die letzte erfolgreich ausführende SQL -Anweisung auf dem Master enthält, der auf dem Sklaven ausgeführt wurde.Exec_Master_Log_Pos
repräsentiert die Position innerhalbRelay_Master_Log_File
Von der letzten erfolgreich ausführenden SQL -Anweisung zum Master, der auf dem Sklaven ausgeführt wurde.
Sie könnten dies gegen dieses binäre Protokoll ausführen:
TMSTMP=`mysqlbinlog ---start-position=EMLP RMFL | head -50 | grep "^SET TIMESTAMP=" | head -1 | sed 's/=/ /g' | sed 's/\// /g' | awk '{print $3}'`
RIGHTNOW=`date +%s`
(( REPLAG = RIGHTNOW - TMSTMP ))
wobei EMLP exec_master_log_pos rmfl ist und die relay_master_log_file ist
Dies ist zwar realistisch der richtige Weg, um die Replikationsverzögerung nur mit der Protokolldatei und der Postition zu erhalten, aber Sie müssen
- Kommunizieren Sie mit dem Sklaven, um die erforderliche Protokolldatei und Position zu erhalten
- Kommunizieren Sie mit dem Meister, um die Müllkopie des Binlogs abzurufen
- Lassen Sie das Binlog jedes Mal, wenn Sie überprüfen, ab (MySQLBINLOG funktioniert sicher, wenn es nicht zum aktuell geöffneten Protokoll ist. Dadurch muss möglicherweise Flush -Protokolle im Master durchgeführt werden, bevor Sie die Master -Protokolldatei abwerfen).
Die Replikationsverzögerung von den binären Protokollen selbst erfordert viel mehr Beinarbeit.
Mk-Heartbeat Überprüft nur einen Herzschlagtabelle und zeichne nur auf. Die Verwendung einer Live -Tabelle auf einem Master und der Vergleich der Kopie des Sklavenkopie der Herzschlagtabelle mit Unix_timestamp () auf dem Sklaven ist eine viel prägnantere Echtzeitmessung.
Du solltest mit Mk-Heartbeat gehen.