MySQL 同期遅延が発生したときに Seconds_Behind_Master が 0 のままになる理由

./sql/rpl_slave.cc

ブール show_slave_status_send_data(THD *thd, Master_info *mi,
                                 char* io_gtid_set_buffer、
                                 char*sql_gtid_set_buffer) の引数
......
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);

      protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   最大値(0L、時間差):0));
    }
......

  /*
     Seconds_Behind_Master を計算する疑似コード:
     if (SQL スレッドが実行中)
     {
       if (SQL スレッドが利用可能なすべてのリレー ログを処理した場合)
       {
         if (IOスレッドが実行中)
            0 を印刷します。
         それ以外
            NULLを印刷します。
       }
        それ以外
          Seconds_Behind_Masterを計算します。
      }
      それ以外
       NULLを印刷します。
  */

./sql/rpl_slave.cc

......
  もし（もし）
  {
    enum_slave_apply_event_and_update_pos_retval exec_res; 列挙型 enum_slave_apply_event_and_update_pos_retval exec_res;

    ptr_ev = &ev; です。
    /*
      このイベントを実行しなくても、マスタータイムスタンプは保持されます。
      マスターの秒数が正しいデルタを示すようにする（イベントがある
      再生されないため、遅れを取り続けます。

      人工的なイベント、またはリレーログイベント（IOスレッドによって生成されたイベント）の場合
      イベント）またはev->whenが0に設定されている場合、またはマスターからのFD、またはハートビート
      server_id が '0' のイベントの場合、last_master_timestamp は更新されません。

      並列実行の場合、last_master_timestampは次の場合にのみ更新されます。
      ジョブはGAQから取り出されます。したがって、last_master_timestampが0（
      GAQが空であることを示し、すべてのスレーブワーカーはイベントを待機しています
      コーディネーターの場合、最初のタイムスタンプで初期化する必要があります
      並行して実行されるイベント。
    */
    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);
    }
......

./sql/rpl\_スレーブ.cc

......
  /*
    この時点でこれが呼び出されないようにする必要があります
    cntはゼロです。この値はチェックポイント情報
    完全にリセットされます。
  */

  /*
    正しい Seconds_behind_master を報告するために rli->last_master_timestamp を更新します。

    GAQ が空の場合はゼロに設定します。
    それ以外の場合は、Slave_job_queueの最初のジョブのタイムスタンプで更新します。
    これは Log_event::get_slave_worker() 関数で割り当てられました。
  */
  ts = rli->gaq->空()
    ? 0
    : reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts;
  rli->reset_notified_checkpoint(cnt、ts、need_data_lock、true);
  /* "Coordinator::"commit_positions" の終了 */

......

  /*
    現在、チェックポイント ルーチンは SQL スレッドによって呼び出されています。
    そのため、この関数は適切なポイントから呼び出されます
    SQLスレッドの実行パスで経過時間が計算されます
    ここで、実行するタイミングを確認します。
  */
  set_timespec_nsec(&curr_clock, 0);
  ulonglong diff = diff_timespec(&curr_clock, &rli->last_clock);
  if (!force && diff < ピリオド)
  {
    /*
      チェックポイントを今すぐ実行する必要はありません。
      経過時間が十分ではありません。
    */
    DBUG_RETURN(偽);
  }