MySQLのSeconds_Behind_Masterの詳細な説明

マスターの後ろの秒数

MySQL マスター/スレーブインスタンスの場合、seconds_behind_master はマスターとスレーブ間の遅延を測定するための重要なパラメーターです。 seconds_behind_master の値は、スレーブ上で「show slave status;」を実行することで取得できます。

オリジナルの実装

定義: スレーブ SQL スレッドがマスターバイナリログの処理に遅れている秒数。

タイプ: time_t (long)

計算は次のようになります。

rpl_slave.cc::show_slave_status_send_data()
if ((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()))) {
     mi->slave_running == MYSQL_SLAVE_RUN_CONNECT の場合
       プロトコル->store(0LL);
     それ以外
       プロトコル->store_null();
   } それ以外 {
     長いtime_diff = ((long)(time(0) - mi->rli->last_master_timestamp) -
                       mi->clock_diff_with_master);
     プロトコル->ストア(
         (longlong)(mi->rli->last_master_timestamp ? max(0L, time_diff) : 0));
   }

主に2つの状況があります:

SQL スレッドは、IO スレッドがホスト binlog を取得するのを待機します。このとき、seconds_behind_master は 0 であり、スタンバイマシンとマスターマシンの間に遅延がないことを示しています。
SQLスレッドはリレーログを処理します。このとき、seconds_behind_masterは(long)(time(0) – mi->rli->last_master_timestamp) – mi->clock_diff_with_masterで計算されます。

最終マスタータイムスタンプ

意味：

マスターデータベース binlog 内のイベントの時刻。

型: time_t (long)

計算方法：

last_master_timestamp は、スタンバイサーバーが並列にレプリケートされるかどうかに応じて計算方法が異なります。

非並列レプリケーション:

rpl_slave.cc:exec_relay_log_event()
if ((!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 +
                             （time_t）ev->exec_time;
 DBUG_ASSERT(rli->last_master_timestamp >= 0);
}

このモードでは、last_master_timestamp は各イベントの終了時刻を示し、when.tv_sec はイベントの開始時刻を示し、exec_time はトランザクションの実行時刻を示します。この値は apply_event の前に計算されるため、イベントが実行される前に last_master_timestamp が更新されます。 exec_time は Query_log_event にのみ存在するため、last_master_timestamp はトランザクションを適用するさまざまなイベント段階で変化します。 2 つの挿入ステートメントを含むトランザクションを例に挙げます。このコードセグメントが呼び出されると、イベントタイプ、タイムスタンプ、実行時間が出力されます。

テーブル t1(a int PRIMARY KEY AUTO_INCREMENT 、b longblob) を作成します。engine=innodb;
始める;
t1(b)に挿入し、repeat('a',104857600);を選択します。
t1(b)に挿入し、repeat('a',104857600);を選択します。
専念;

10T06:41:32.628554Z 11 [注記] [MY-000000] [Repl] event_type: 33 GTID_LOG_EVENT
2020-02-10T06:41:32.628601Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316890
2020-02-10T06:41:32.628614Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:32.628692Z 11 [メモ] [MY-000000] [Repl] event_type: 2 QUERY_EVENT
2020-02-10T06:41:32.628704Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:32.628713Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 35
2020-02-10T06:41:32.629037Z 11 [メモ] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT
2020-02-10T06:41:32.629057Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:32.629063Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:33.644111Z 11 [メモ] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT
2020-02-10T06:41:33.644149Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:33.644156Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:43.520272Z 0 [注記] [MY-011953] [InnoDB] ページクリーナーは 3 ページのフラッシュと 0 ページの削除に 9185 ミリ秒かかりました
2020-02-10T06:42:05.982458Z 11 [メモ] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT
2020-02-10T06:42:05.982488Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316858
2020-02-10T06:42:05.982495Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:42:06.569345Z 11 [メモ] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT
2020-02-10T06:42:06.569376Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316858
2020-02-10T06:42:06.569384Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:42:16.506176Z 0 [注記] [MY-011953] [InnoDB] ページクリーナーは 8 ページのフラッシュと 0 ページの削除に 9352 ミリ秒かかりました
2020-02-10T06:42:37.202507Z 11 [メモ] [MY-000000] [Repl] event_type: 16 XID_EVENT
2020-02-10T06:42:37.202539Z 11 [メモ] [MY-000000] [Repl] event_time: 1581316890
2020-02-10T06:42:37.202546Z 11 [メモ] [MY-000000] [Repl] event_exec_time: 0

並列レプリケーション:

rpl_slave.cc mts_checkpoint_routine
ts = rli->gaq->空()
          ? 0
          : reinterpret_cast<Slave_job_group *>(rli->gaq->head_queue())->ts;
 rli->reset_notified_checkpoint(cnt, ts, true);
 /* "Coordinator::"commit_positions" の終了 */

このモードでは、スタンバイマシン上に分散キュー gaq が存在します。gaq が空の場合、last_commit_timestamp は 0 に設定されます。gaq が空でない場合、この時点でチェックポイントポイント lwm が維持され、lwm より前のトランザクションはすべてスタンバイマシン上で完了します。このとき、last_commit_timestamp は lwm が配置されているトランザクションが完了した後の時間に更新されます。時間型はtime_t型です。

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

if (update_timestamp) {
 mysql_mutex_lock(&data_lock);
 last_master_timestamp = new_ts;
 mysql_mutex_unlock(&data_lock);
}

並列レプリケーションでは、last_master_timestamp はイベント実行が完了した後にのみ更新されるため、seconds_behind_master は非並列レプリケーションと並列レプリケーションで異なります。

マスターとのクロック差

意味：

マスターのクロックとスレーブのクロックの差 (秒 - 1 秒)。<0 または >0 になる可能性があるため、符号を付ける必要があります。clock_diff_with_master は、I/O スレッドの開始時に計算されます。このため、I/O スレッドはマスターで SELECT UNIX_TIMESTAMP() を実行します。
タイプ: ロング

rpl_slave.cc::get_master_version_and_clock()
if (!mysql_real_query(mysql, STRING_WITH_LEN("SELECT UNIX_TIMESTAMP()")) &&
     (master_res = mysql_store_result(mysql)) &&
     (master_row = mysql_fetch_row(master_res)))
 {
   mysql_mutex_lock(&mi->data_lock);
   mi->クロックの差_with_master=
     (long) (time((time_t*) 0) - strtoul(master_row[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);
 }

この差は、マスターとスレーブが接続を確立したときに 1 回だけ計算されます。

他の

実行時間

意味：

ステートメントの元の開始タイムスタンプと実行が完了した時刻との差。
型: 符号なしlong

構造体timeval終了時間;
ulonglong micro_end_time = my_micro_time();
my_micro_time_to_timeval(micro_end_time、&end_time);
exec_time = end_time.tv_sec - thd_arg->query_start_in_secs();

時間関数

(1) time_t time(time_t timer) time_tはlong型であり、返される値は秒単位の精度のみです。

（２）int gettimeofday（struct timeval *tv, struct timezone *tz）はマイクロ秒単位で現在の時刻を取得できる。

（３）タイムバル構造

#include <time.h>
構造体timeval {
   time_t tv_sec; /*秒*/
   suseconds_t tv_usec; /*マイクロ秒*/
}

要約する

seconds_behind_master を使用してマスターとスレーブ間の遅延を測定すると、秒単位までしか正確ではありません。シナリオによっては、seconds_behind_master ではマスターとスレーブ間の遅延を正確に反映できない場合があります。マスターとスタンバイに異常がある場合は、seconds_behind_master ソースコードを組み合わせて具体的な分析を行うことができます。

以上がMySQL Seconds_Behind_Masterの詳しい説明です。MySQL Seconds_Behind_Masterの詳細については、123WORDPRESS.COMの他の関連記事もご覧ください。

以下もご興味があるかもしれません: