最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

MySQL 發(fā)生同步延遲時Seconds_Behind_Master還為0的原因

 更新時間:2021年06月21日 10:06:36   作者:王文安@DBA  
騰訊云數(shù)據(jù)庫 MySQL 的只讀實例出現(xiàn)了同步延遲,但是監(jiān)控的延遲時間顯示為 0,而且延遲的 binlog 距離非 0,且數(shù)值越來越大。臨時解決之后,仔細(xì)想了一想,Seconds_Behind_Master 雖然計算方式有點坑,但是出現(xiàn)這么“巨大”的誤差還是挺奇怪的,本文就來分析下這個問題

問題描述

用戶在主庫上執(zhí)行了一個 alter 操作,持續(xù)約一小時。操作完成之后,從庫發(fā)現(xiàn)存在同步延遲,但是監(jiān)控圖表中的 Seconds_Behind_Master 指標(biāo)顯示為 0,且 binlog 的延遲距離在不斷上升。

原理簡析

既然是分析延遲時間,那么自然先從延遲的計算方式開始入手。為了方便起見,此處引用官方版本 5.7.31 的源代碼進(jìn)行閱讀。找到計算延遲時間的代碼:

./sql/rpl_slave.cc

bool 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())))
    {
      if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
        protocol->store(0LL);
      else
        protocol->store_null();
    }
    else
    {
      long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)
                       - mi->clock_diff_with_master);

      protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   max(0L, time_diff) : 0));
    }
......

從 time_diff 的計算方式來看,可以發(fā)現(xiàn)這個延遲基本上就是一個時間差值,然后再算上主從之間的時間差。不過 if 挺多的,所以借用源代碼文件中的注釋:

  /*
     The pseudo code to compute Seconds_Behind_Master:
     if (SQL thread is running)
     {
       if (SQL thread processed all the available relay log)
       {
         if (IO thread is running)
            print 0;
         else
            print NULL;
       }
        else
          compute Seconds_Behind_Master;
      }
      else
       print NULL;
  */

可以知道,Seconds_Behind_Master的計算分為兩個部分:

  • SQL 線程正常,且回放完所有的 relaylog 時,如果 IO 線程正常,那么直接置 0。
  • SQL 線程正常,且回放完所有的 relaylog 時,如果 IO 線程不正常,那么直接置 NULL。
  • SQL 線程正常,且沒有回放完所有的 relaylog 時,計算延遲時間。

那么在最后計算延遲時間的時候,看看那幾個變量代表的意義:

  • time(0):當(dāng)前的時間戳,timestamp 格式的。
  • last_master_timestamp:這個 event 在主庫上執(zhí)行的時刻,timestamp 格式。
  • clock_diff_with_master:slave 和 master 的時間差,在 IO 線程啟動時獲取的。

由此可見,延遲計算的時候,實際上是以 slave 本地的時間來減掉回放的這個 event 在 master 執(zhí)行的時刻,再補償兩者之間的時間差,最后得到的一個數(shù)值。從邏輯上看是沒什么問題的,由于 time(0) 和 clock_diff_with_master 在大多數(shù)時候是沒有什么出問題的機(jī)會的,所以這次的問題,應(yīng)該是出在 last_master_timestamp 上了。

PS:雖說大部分時候沒問題,但是 time(0) 取的是本地時間,因此 slave 的本地時間有問題的話,這個最終的值也會出錯,不過不在本案例的問題討論范圍之內(nèi)了。

那么找一下執(zhí)行 event 的時候,計算last_master_timestamp的邏輯,結(jié)合注釋可以發(fā)現(xiàn)普通復(fù)制和并行復(fù)制用了不同的計算方式,第一個是普通的復(fù)制,計算時間點在執(zhí)行 event 之前:

./sql/rpl_slave.cc

......
  if (ev)
  {
    enum enum_slave_apply_event_and_update_pos_retval exec_res;

    ptr_ev= &ev;
    /*
      Even if we don't execute this event, we keep the master timestamp,
      so that seconds behind master shows correct delta (there are events
      that are not replayed, so we keep falling behind).

      If it is an artificial event, or a relay log event (IO thread generated
      event) or ev->when is set to 0, or a FD from master, or a heartbeat
      event with server_id '0' then  we don't update the last_master_timestamp.

      In case of parallel execution last_master_timestamp is only updated when
      a job is taken out of GAQ. Thus when last_master_timestamp is 0 (which
      indicates that GAQ is empty, all slave workers are waiting for events from
      the Coordinator), we need to initialize it with a timestamp from the first
      event to be executed in parallel.
    */
    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的值是取了 event 的開始時間并加上執(zhí)行時間,在 5.7 中有不少 event 是沒有執(zhí)行時間這個數(shù)值的,8.0 給很多 event 添加了這個數(shù)值,因此也算是升級 8.0 之后帶來的好處。

而并行復(fù)制的計算方式,參考如下這一段代碼:

./sql/rpl\_slave.cc

......
  /*
    We need to ensure that this is never called at this point when
    cnt is zero. This value means that the checkpoint information
    will be completely reset.
  */

  /*
    Update the rli->last_master_timestamp for reporting correct Seconds_behind_master.

    If GAQ is empty, set it to zero.
    Else, update it with the timestamp of the first job of the Slave_job_queue
    which was assigned in the Log_event::get_slave_worker() function.
  */
  ts= rli->gaq->empty()
    ? 0
    : reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts;
  rli->reset_notified_checkpoint(cnt, ts, need_data_lock, true);
  /* end-of "Coordinator::"commit_positions" */

......

在 Coordinator 的 commit_positions 這個邏輯中,如果 gaq 隊列為空,那么last_master_timestamp直接置 0,否則會選擇 gaq 隊列的第一個 job 的時間戳。需要補充一點的是,這個計算并不是實時的,而是間歇性的,在計算邏輯前面,有如下的邏輯:

  /*
    Currently, the checkpoint routine is being called by the SQL Thread.
    For that reason, this function is called call from appropriate points
    in the SQL Thread's execution path and the elapsed time is calculated
    here to check if it is time to execute it.
  */
  set_timespec_nsec(&curr_clock, 0);
  ulonglong diff= diff_timespec(&curr_clock, &rli->last_clock);
  if (!force && diff < period)
  {
    /*
      We do not need to execute the checkpoint now because
      the time elapsed is not enough.
    */
    DBUG_RETURN(FALSE);
  }

即在這個 period 的時間間隔之內(nèi),會直接 return,并不會更新這個last_master_timestamp,所以有時候也會發(fā)現(xiàn)并行復(fù)制會時不時出現(xiàn) Seconds_Behind_Master 在數(shù)值上從 0 到 1 的變化。

而 gaq 隊列的操作,估計是類似于入棧退棧的操作,所以留在 gaq 的總是沒有執(zhí)行完的事務(wù),因此時間計算從一般場景的角度來看是沒問題。

問題分析

原理簡析中簡要闡述了整個計算的邏輯,那么回到這個問題本身,騰訊云數(shù)據(jù)庫 MySQL 默認(rèn)是開啟了并行復(fù)制的,因此會存在 gaq 隊列,而 alter 操作耗時非常的長,不論 alter 操作是否會被放在一組并行事務(wù)中執(zhí)行(大概率,DDL 永遠(yuǎn)是一個單獨的事務(wù)組),最終都會出現(xiàn) gaq 隊列持續(xù)為空,那么就會把last_master_timestamp置 0,而參考 Seconds_Behind_Master 的計算邏輯,最終的 time_diff 也會被置 0,因此 alter 操作結(jié)束前的延遲時間一直會是 0。而當(dāng) alter 操作執(zhí)行完之后,gaq 隊列會填充新的 event 和事務(wù),所以會出現(xiàn)延遲之前一直是 0,但是突然跳到非常高的現(xiàn)象。

拓展一下

對比普通復(fù)制和并行復(fù)制計算方式上的差異,可以知道以下幾個特點:

  • 開啟并行復(fù)制之后,延遲時間會經(jīng)常性的在 0 和 1 之間跳變。
  • alter 操作,單個大事務(wù)等在并行復(fù)制的場景下容易導(dǎo)致延遲時間不準(zhǔn),而普通的復(fù)制方式不會。
  • 由于主從時間差是在 IO 線程啟動時就計算好的,所以期間 slave 的時間出現(xiàn)偏差之后,延遲時間也會出現(xiàn)偏差。

總結(jié)一下

嚴(yán)謹(jǐn)?shù)难舆t判斷,還是依靠 GTID 的差距和 binlog 的 position 差距會比較好,從 8.0 的 event 執(zhí)行時間變化來看,至少 Oracle 官方還是在認(rèn)真干活的,希望這些小毛病能盡快的修復(fù)吧。

以上就是MySQL 發(fā)生同步延遲時Seconds_Behind_Master還為0的原因的詳細(xì)內(nèi)容,更多關(guān)于MySQL 同步延遲Seconds_Behind_Master為0的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • 解決MYSQL連接端口被占引入文件路徑錯誤的問題

    解決MYSQL連接端口被占引入文件路徑錯誤的問題

    下面小編就為大家?guī)硪黄鉀QMYSQL連接端口被占引入文件路徑錯誤的問題。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2017-08-08
  • MySQL多表查詢的具體實例

    MySQL多表查詢的具體實例

    這篇文章主要介紹了MySQL多表查詢的具體實例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2021-01-01
  • MySql數(shù)據(jù)庫備份的幾種方式

    MySql數(shù)據(jù)庫備份的幾種方式

    這篇文章主要介紹了MySql數(shù)據(jù)庫備份的幾種方式,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-12-12
  • 史上最簡單的MySQL數(shù)據(jù)備份與還原教程(下)(三十七)

    史上最簡單的MySQL數(shù)據(jù)備份與還原教程(下)(三十七)

    這篇文章主要為大家詳細(xì)介紹了史上最簡單的MySQL數(shù)據(jù)備份與還原教程下篇,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2017-10-10
  • MySQL MEM_ROOT詳解及實例代碼

    MySQL MEM_ROOT詳解及實例代碼

    mysql中使用MEM_ROOT來做內(nèi)存分配的部分,這篇文章會詳細(xì)解說MySQL中使用非常廣泛的MEM_ROOT的結(jié)構(gòu)體,同時省去debug部分的信息,僅分析正常情況下。需要的朋友可以參考一下
    2016-11-11
  • 詳解MySQL 數(shù)據(jù)庫范式

    詳解MySQL 數(shù)據(jù)庫范式

    這篇文章主要介紹了詳解MySQL 數(shù)據(jù)庫范式的相關(guān)資料,幫助大家更好的理解和學(xué)習(xí)MySQL,感興趣的朋友可以了解下
    2020-11-11
  • 防止mysql重復(fù)插入記錄的方法

    防止mysql重復(fù)插入記錄的方法

    這篇文章主要為大家詳細(xì)介紹了防止mysql重復(fù)插入記錄的方法,感興趣的小伙伴們可以參考一下
    2016-05-05
  • MySQL通過show status查看、explain分析優(yōu)化數(shù)據(jù)庫性能

    MySQL通過show status查看、explain分析優(yōu)化數(shù)據(jù)庫性能

    這篇文章介紹了MySQL通過show status查看、explain分析優(yōu)化數(shù)據(jù)庫性能的方法,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2022-04-04
  • mysql中的limit 1 for update的鎖類型

    mysql中的limit 1 for update的鎖類型

    這篇文章主要介紹了mysql中的limit 1 for update的鎖類型,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2023-08-08
  • 點贊功能使用MySQL還是Redis

    點贊功能使用MySQL還是Redis

    本文主要介紹了點贊功能使用MySQL還是Redis,這是最近面試時被問到的1道面試題,本篇博客對此問題進(jìn)行總結(jié)分享,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2021-12-12

最新評論

翁牛特旗| 武川县| 中超| 青神县| 延长县| 泗阳县| 五大连池市| 舟曲县| 焦作市| 微博| 南皮县| 民乐县| 博乐市| 札达县| 密山市| 青川县| 彰化县| 应城市| 兴文县| 罗甸县| 武定县| 华池县| 资源县| 万州区| 黑龙江省| 石景山区| 昭觉县| 庄河市| 阳新县| 雅江县| 宜黄县| 精河县| 普兰店市| 宜阳县| 隆昌县| 大邑县| 珠海市| 通化县| 义乌市| 衡水市| 尖扎县|