Detaillierte Erklärung von MySQLs Seconds_Behind_Master

Sekunden_hinter_Master

Für MySQL Master-Slave-Instanzen ist seconds_behind_master ein wichtiger Parameter zum Messen der Verzögerung zwischen Master und Slave. Der Wert von seconds_behind_master kann durch Ausführen von „show slave status;“ auf dem Slave abgerufen werden.

Ursprüngliche Implementierung

Definition: Die Anzahl der Sekunden, die der Slave-SQL-Thread bei der Verarbeitung des Master-Binärprotokolls im Rückstand ist.

Typ: time_t (long)

Die Berechnung erfolgt wie folgt:

rpl_slave.cc::show_slave_status_send_data()
wenn ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) &&
       (!strcmp(mi->get_master_log_name(),
                mi->rli->get_group_master_log_name()))) {
     wenn (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
       Protokoll->Speichern(0LL);
     anders
       Protokoll->store_null();
   } anders {
     langer Zeitunterschied = ((lang)(Zeit(0) - mi->rli->letzter_Masterzeitstempel) -
                       mi->Uhr_Differenz_mit_Master);
     Protokoll->Speichern(
         (langlang)(mi->rli->letzter_Masterzeitstempel ? max(0L, Zeitdifferenz) : 0));
   }

Es gibt hauptsächlich zwei Situationen:

• Der SQL-Thread wartet darauf, dass der IO-Thread das Host-Binlog erhält. Zu diesem Zeitpunkt ist seconds_behind_master 0, was bedeutet, dass zwischen der Standby-Maschine und der Master-Maschine keine Verzögerung besteht.
• Der SQL-Thread verarbeitet das Relay-Protokoll. Zu diesem Zeitpunkt wird seconds_behind_master wie folgt berechnet: (long)(time(0) – mi->rli->last_master_timestamp) – mi->clock_diff_with_master.

letzter_Masterzeitstempel

Definition:

Der Zeitpunkt des Ereignisses im Binärprotokoll der Masterdatenbank.

Typ: time_t (lang)

Berechnungsmethode:

Der last_master_timestamp wird unterschiedlich berechnet, je nachdem, ob der Standby-Server parallel repliziert wird.

Nicht-parallele Replikation:

rpl_slave.cc:exec_relay_log_event()
wenn ((!rli->is_parallel_exec() || rli->last_master_timestamp == 0) &&
    !(ev->is_artificial_event() || ev->is_relay_log_event() ||
     (ev->common_header->when.tv_sec == 0) ||
     ev->get_type_code() == binary_log::FORMAT_DESCRIPTION_EVENT ||
     ev->server_id == 0))
{
 rli->last_master_timestamp = ev->common_header->when.tv_sec +
                             (Zeit_t) ev->Ausführungszeit;
 DBUG_ASSERT(rli->last_master_timestamp >= 0);
}

In diesem Modus gibt last_master_timestamp die Endzeit jedes Ereignisses an, when.tv_sec die Startzeit des Ereignisses und exec_time die Ausführungszeit der Transaktion. Dieser Wert wird vor dem Apply_Event berechnet, sodass der Last_Master_Timestamp vor der Ausführung des Ereignisses aktualisiert wurde. Da exec_time nur im Query_log_event vorhanden ist, ändert sich last_master_timestamp in verschiedenen Ereignisphasen der Anwendung einer Transaktion. Nehmen wir als Beispiel eine Transaktion, die zwei Einfügeanweisungen enthält. Wenn dieser Codeabschnitt aufgerufen wird, werden Ereignistyp, Zeitstempel und Ausführungszeit ausgedruckt.

Erstellen Sie Tabelle t1 (a int PRIMARY KEY AUTO_INCREMENT, b longblob) engine=innodb;
beginnen;
in t1(b) einfügen, auswählen, wiederholen('a',104857600);
in t1(b) einfügen, auswählen, wiederholen('a',104857600);
begehen;

10T06:41:32.628554Z 11 [Hinweis] [MY-000000] [Repl] event_type: 33 GTID_LOG_EVENT

2020-02-10T06:41:32.628601Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316890

2020-02-10T06:41:32.628614Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

2020-02-10T06:41:32.628692Z 11 [Hinweis] [MY-000000] [Repl] event_type: 2 QUERY_EVENT

2020-02-10T06:41:32.628704Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316823

2020-02-10T06:41:32.628713Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 35

2020-02-10T06:41:32.629037Z 11 [Hinweis] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT

2020-02-10T06:41:32.629057Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316823

2020-02-10T06:41:32.629063Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

2020-02-10T06:41:33.644111Z 11 [Hinweis] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT

2020-02-10T06:41:33.644149Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316823

2020-02-10T06:41:33.644156Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

2020-02-10T06:41:43.520272Z 0 [Hinweis] [MY-011953] [InnoDB] Der Seitenreiniger benötigte 9185 ms, um 3 Seiten zu leeren und 0 Seiten zu entfernen

2020-02-10T06:42:05.982458Z 11 [Hinweis] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT

2020-02-10T06:42:05.982488Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316858

2020-02-10T06:42:05.982495Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

2020-02-10T06:42:06.569345Z 11 [Hinweis] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT

2020-02-10T06:42:06.569376Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316858

2020-02-10T06:42:06.569384Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

2020-02-10T06:42:16.506176Z 0 [Hinweis] [MY-011953] [InnoDB] Der Seitenreiniger benötigte 9352 ms, um 8 zu leeren und 0 Seiten zu entfernen

2020-02-10T06:42:37.202507Z 11 [Hinweis] [MY-000000] [Repl] event_type: 16 XID_EVENT

2020-02-10T06:42:37.202539Z 11 [Hinweis] [MY-000000] [Repl] event_time: 1581316890

2020-02-10T06:42:37.202546Z 11 [Hinweis] [MY-000000] [Repl] event_exec_time: 0

Parallele Replikation:

rpl_slave.cc mts_checkpoint_routine
ts = rli->gaq->leer()
          ? 0
          : neu interpretieren_cast<Slave_job_group *>(rli->gaq->head_queue())->ts;
 rli->reset_notified_checkpoint(cnt, ts, true);
 /* Ende von "Koordinator::"commit_positions" */

In diesem Modus gibt es auf dem Standby-Rechner eine Verteilungswarteschlange gaq. Wenn gaq leer ist, wird last_commit_timestamp auf 0 gesetzt; wenn gaq nicht leer ist, wird zu diesem Zeitpunkt ein Prüfpunkt lwm beibehalten und alle Transaktionen vor lwm werden auf dem Standby-Rechner abgeschlossen. Zu diesem Zeitpunkt wird last_commit_timestamp auf den Zeitpunkt nach Abschluss der Transaktion aktualisiert, in der sich lwm befindet. Der Zeittyp ist vom Typ time_t.

ptr_group->ts = common_header->when.tv_sec +
                   (time_t)exec_time; // Seconds_behind_master bezogen
rli->rli_checkpoint_seqno++;

wenn (Zeitstempel aktualisieren) {
 mysql_mutex_lock(&data_lock);
 letzter_Masterzeitstempel = neuer_Zeitstempel;
 mysql_mutex_unlock(&data_lock);
}

Bei der parallelen Replikation wird last_master_timestamp erst aktualisiert, nachdem die Ereignisausführung abgeschlossen ist. Daher unterscheidet sich seconds_behind_master zwischen nicht paralleler Replikation und paralleler Replikation.

Uhr_Differenz_mit_Master

Definition:

• Die Differenz in Sekunden zwischen der Uhr des Masters und der Uhr des Slaves (Sekunde - Erste). Sie muss ein Vorzeichen haben, da sie <0 oder >0 sein kann. clock_diff_with_master wird berechnet, wenn der I/O-Thread startet; dazu führt der I/O-Thread ein SELECT UNIX_TIMESTAMP() auf dem Master aus.
• Typ: lang

rpl_slave.cc::get_master_version_and_clock()
wenn (!mysql_real_query(mysql, STRING_WITH_LEN("SELECT UNIX_TIMESTAMP()")) &&
     (master_res = mysql_store_result(mysql)) &&
     (Masterzeile = mysql_fetch_row(Masterres)))
 {
   mysql_mutex_lock(&mi->data_lock);
   mi->clock_diff_with_master=
     (lang) (Zeit((Zeit_t*) 0) - strtoul(Masterzeile[0], 0, 10));
   DBUG_EXECUTE_IF("dbug.mts.force_clock_diff_eq_0",
     mi->clock_diff_with_master = 0;);
   mysql_mutex_unlock(&mi->data_lock);
 }

Diese Differenz wird nur einmal berechnet, wenn Master und Slave Kontakt aufnehmen.

andere

Ausführungszeit

Definition:

• die Differenz zwischen dem ursprünglichen Startzeitstempel der Anweisung und dem Zeitpunkt, zu dem die Ausführung abgeschlossen wurde.
• Typ: unsigned long

Struktur timeval end_time;
ulonglong micro_end_time = meine_micro_zeit();
meine_Mikro_Zeit_bis_Zeitwert(Mikro_Endzeit, &Endzeit);
exec_time = end_time.tv_sec - thd_arg->query_start_in_secs();

Zeitfunktion

(1) time_t time(time_t timer) time_t ist vom Typ „long“ und der zurückgegebene Wert ist nur auf Sekunden genau.

(2) int gettimeofday (struct timeval *tv, struct timezone *tz) kann die aktuelle Zeit in Mikrosekunden ermitteln;

(3) Zeitwertstruktur

#include <zeit.h>
Struktur timeval {
   time_t tv_sec; /*Sekunden*/
   suseconds_t tv_usec; ​​​​/*Mikrosekunden*/
}

Zusammenfassen

Die Verwendung von seconds_behind_master zur Messung der Master-Slave-Verzögerung kann nur auf Sekundenebene genau sein. In einigen Szenarien kann seconds_behind_master die Verzögerung zwischen Master und Slave nicht genau wiedergeben. Wenn beim Master und Standby Störungen auftreten, können Sie den Seconds_behind_Master-Quellcode für eine spezifische Analyse kombinieren.

Oben finden Sie eine ausführliche Erklärung zu MySQL Seconds_Behind_Master. Weitere Informationen zu MySQL Seconds_Behind_Master finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!