<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
使用者在主庫上執行了一個 alter 操作,持續約一小時。操作完成之後,從庫發現存在同步延遲,但是監控圖表中的 Seconds_Behind_Master 指標顯示為 0,且 binlog 的延遲距離在不斷上升。
既然是分析延遲時間,那麼自然先從延遲的計算方式開始入手。為了方便起見,此處參照官方版本 5.7.31 的原始碼進行閱讀。找到計算延遲時間的程式碼:
./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 的計算方式來看,可以發現這個延遲基本上就是一個時間差值,然後再算上主從之間的時間差。不過 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的計算分為兩個部分:
那麼在最後計算延遲時間的時候,看看那幾個變數代表的意義:
由此可見,延遲計算的時候,實際上是以 slave 原生的時間來減掉回放的這個 event 在 master 執行的時刻,再補償兩者之間的時間差,最後得到的一個數值。從邏輯上看是沒什麼問題的,由於 time(0) 和 clock_diff_with_master 在大多數時候是沒有什麼出問題的機會的,所以這次的問題,應該是出在 last_master_timestamp 上了。
PS:雖說大部分時候沒問題,但是 time(0) 取的是本地時間,因此 slave 的本地時間有問題的話,這個最終的值也會出錯,不過不在本案例的問題討論範圍之內了。
那麼找一下執行 event 的時候,計算last_master_timestamp的邏輯,結合註釋可以發現普通複製和並行複製用了不同的計算方式,第一個是普通的複製,計算時間點在執行 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 的開始時間並加上執行時間,在 5.7 中有不少 event 是沒有執行時間這個數值的,8.0 給很多 event 新增了這個數值,因此也算是升級 8.0 之後帶來的好處。
而並行複製的計算方式,參考如下這一段程式碼:
./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 的時間間隔之內,會直接 return,並不會更新這個last_master_timestamp,所以有時候也會發現並行複製會時不時出現 Seconds_Behind_Master 在數值上從 0 到 1 的變化。
而 gaq 佇列的操作,估計是類似於入棧退棧的操作,所以留在 gaq 的總是沒有執行完的事務,因此時間計算從一般場景的角度來看是沒問題。
原理簡析中簡要闡述了整個計算的邏輯,那麼回到這個問題本身,騰訊雲資料庫 MySQL 預設是開啟了並行複製的,因此會存在 gaq 佇列,而 alter 操作耗時非常的長,不論 alter 操作是否會被放在一組並行事務中執行(大概率,DDL 永遠是一個單獨的事務組),最終都會出現 gaq 佇列持續為空,那麼就會把last_master_timestamp置 0,而參考 Seconds_Behind_Master 的計算邏輯,最終的 time_diff 也會被置 0,因此 alter 操作結束前的延遲時間一直會是 0。而當 alter 操作執行完之後,gaq 佇列會填充新的 event 和事務,所以會出現延遲之前一直是 0,但是突然跳到非常高的現象。
對比普通複製和並行複製計算方式上的差異,可以知道以下幾個特點:
嚴謹的延遲判斷,還是依靠 GTID 的差距和 binlog 的 position 差距會比較好,從 8.0 的 event 執行時間變化來看,至少 Oracle 官方還是在認真幹活的,希望這些小毛病能儘快的修復吧。
以上就是MySQL 發生同步延遲時Seconds_Behind_Master還為0的原因的詳細內容,更多關於MySQL 同步延遲Seconds_Behind_Master為0的資料請關注it145.com其它相關文章!
相關文章
<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
综合看Anker超能充系列的性价比很高,并且与不仅和iPhone12/苹果<em>Mac</em>Book很配,而且适合多设备充电需求的日常使用或差旅场景,不管是安卓还是Switch同样也能用得上它,希望这次分享能给准备购入充电器的小伙伴们有所
2021-06-01 09:31:42
除了L4WUDU与吴亦凡已经多次共事,成为了明面上的厂牌成员,吴亦凡还曾带领20XXCLUB全队参加2020年的一场音乐节,这也是20XXCLUB首次全员合照,王嗣尧Turbo、陈彦希Regi、<em>Mac</em> Ova Seas、林渝植等人全部出场。然而让
2021-06-01 09:31:34
目前应用IPFS的机构:1 谷歌<em>浏览器</em>支持IPFS分布式协议 2 万维网 (历史档案博物馆)数据库 3 火狐<em>浏览器</em>支持 IPFS分布式协议 4 EOS 等数字货币数据存储 5 美国国会图书馆,历史资料永久保存在 IPFS 6 加
2021-06-01 09:31:24
开拓者的车机是兼容苹果和<em>安卓</em>,虽然我不怎么用,但确实兼顾了我家人的很多需求:副驾的门板还配有解锁开关,有的时候老婆开车,下车的时候偶尔会忘记解锁,我在副驾驶可以自己开门:第二排设计很好,不仅配置了一个很大的
2021-06-01 09:30:48
不仅是<em>安卓</em>手机,苹果手机的降价力度也是前所未有了,iPhone12也“跳水价”了,发布价是6799元,如今已经跌至5308元,降价幅度超过1400元,最新定价确认了。iPhone12是苹果首款5G手机,同时也是全球首款5nm芯片的智能机,它
2021-06-01 09:30:45