MySQL 發(fā)生同步延遲時(shí)Seconds_Behind_Master還為0的原因
問題描述
用戶在主庫上執(zhí)行了一個(gè) alter 操作,持續(xù)約一小時(shí)。操作完成之后,從庫發(fā)現(xiàn)存在同步延遲,但是監(jiān)控圖表中的 Seconds_Behind_Master 指標(biāo)顯示為 0,且 binlog 的延遲距離在不斷上升。
原理簡析
既然是分析延遲時(shí)間,那么自然先從延遲的計(jì)算方式開始入手。為了方便起見,此處引用官方版本 5.7.31 的源代碼進(jìn)行閱讀。找到計(jì)算延遲時(shí)間的代碼:
./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 的計(jì)算方式來看,可以發(fā)現(xiàn)這個(gè)延遲基本上就是一個(gè)時(shí)間差值,然后再算上主從之間的時(shí)間差。不過 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的計(jì)算分為兩個(gè)部分:
- SQL 線程正常,且回放完所有的 relaylog 時(shí),如果 IO 線程正常,那么直接置 0。
- SQL 線程正常,且回放完所有的 relaylog 時(shí),如果 IO 線程不正常,那么直接置 NULL。
- SQL 線程正常,且沒有回放完所有的 relaylog 時(shí),計(jì)算延遲時(shí)間。
那么在最后計(jì)算延遲時(shí)間的時(shí)候,看看那幾個(gè)變量代表的意義:
- time(0):當(dāng)前的時(shí)間戳,timestamp 格式的。
- last_master_timestamp:這個(gè) event 在主庫上執(zhí)行的時(shí)刻,timestamp 格式。
- clock_diff_with_master:slave 和 master 的時(shí)間差,在 IO 線程啟動時(shí)獲取的。
由此可見,延遲計(jì)算的時(shí)候,實(shí)際上是以 slave 本地的時(shí)間來減掉回放的這個(gè) event 在 master 執(zhí)行的時(shí)刻,再補(bǔ)償兩者之間的時(shí)間差,最后得到的一個(gè)數(shù)值。從邏輯上看是沒什么問題的,由于 time(0) 和 clock_diff_with_master 在大多數(shù)時(shí)候是沒有什么出問題的機(jī)會的,所以這次的問題,應(yīng)該是出在 last_master_timestamp 上了。
PS:雖說大部分時(shí)候沒問題,但是 time(0) 取的是本地時(shí)間,因此 slave 的本地時(shí)間有問題的話,這個(gè)最終的值也會出錯(cuò),不過不在本案例的問題討論范圍之內(nèi)了。
那么找一下執(zhí)行 event 的時(shí)候,計(jì)算last_master_timestamp的邏輯,結(jié)合注釋可以發(fā)現(xiàn)普通復(fù)制和并行復(fù)制用了不同的計(jì)算方式,第一個(gè)是普通的復(fù)制,計(jì)算時(shí)間點(diǎn)在執(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 的開始時(shí)間并加上執(zhí)行時(shí)間,在 5.7 中有不少 event 是沒有執(zhí)行時(shí)間這個(gè)數(shù)值的,8.0 給很多 event 添加了這個(gè)數(shù)值,因此也算是升級 8.0 之后帶來的好處。
而并行復(fù)制的計(jì)算方式,參考如下這一段代碼:
./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 這個(gè)邏輯中,如果 gaq 隊(duì)列為空,那么last_master_timestamp直接置 0,否則會選擇 gaq 隊(duì)列的第一個(gè) job 的時(shí)間戳。需要補(bǔ)充一點(diǎn)的是,這個(gè)計(jì)算并不是實(shí)時(shí)的,而是間歇性的,在計(jì)算邏輯前面,有如下的邏輯:
/* 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); }
即在這個(gè) period 的時(shí)間間隔之內(nèi),會直接 return,并不會更新這個(gè)last_master_timestamp,所以有時(shí)候也會發(fā)現(xiàn)并行復(fù)制會時(shí)不時(shí)出現(xiàn) Seconds_Behind_Master 在數(shù)值上從 0 到 1 的變化。
而 gaq 隊(duì)列的操作,估計(jì)是類似于入棧退棧的操作,所以留在 gaq 的總是沒有執(zhí)行完的事務(wù),因此時(shí)間計(jì)算從一般場景的角度來看是沒問題。
問題分析
原理簡析中簡要闡述了整個(gè)計(jì)算的邏輯,那么回到這個(gè)問題本身,騰訊云數(shù)據(jù)庫 MySQL 默認(rèn)是開啟了并行復(fù)制的,因此會存在 gaq 隊(duì)列,而 alter 操作耗時(shí)非常的長,不論 alter 操作是否會被放在一組并行事務(wù)中執(zhí)行(大概率,DDL 永遠(yuǎn)是一個(gè)單獨(dú)的事務(wù)組),最終都會出現(xiàn) gaq 隊(duì)列持續(xù)為空,那么就會把last_master_timestamp置 0,而參考 Seconds_Behind_Master 的計(jì)算邏輯,最終的 time_diff 也會被置 0,因此 alter 操作結(jié)束前的延遲時(shí)間一直會是 0。而當(dāng) alter 操作執(zhí)行完之后,gaq 隊(duì)列會填充新的 event 和事務(wù),所以會出現(xiàn)延遲之前一直是 0,但是突然跳到非常高的現(xiàn)象。
拓展一下
對比普通復(fù)制和并行復(fù)制計(jì)算方式上的差異,可以知道以下幾個(gè)特點(diǎn):
- 開啟并行復(fù)制之后,延遲時(shí)間會經(jīng)常性的在 0 和 1 之間跳變。
- alter 操作,單個(gè)大事務(wù)等在并行復(fù)制的場景下容易導(dǎo)致延遲時(shí)間不準(zhǔn),而普通的復(fù)制方式不會。
- 由于主從時(shí)間差是在 IO 線程啟動時(shí)就計(jì)算好的,所以期間 slave 的時(shí)間出現(xiàn)偏差之后,延遲時(shí)間也會出現(xiàn)偏差。
總結(jié)一下
嚴(yán)謹(jǐn)?shù)难舆t判斷,還是依靠 GTID 的差距和 binlog 的 position 差距會比較好,從 8.0 的 event 執(zhí)行時(shí)間變化來看,至少 Oracle 官方還是在認(rèn)真干活的,希望這些小毛病能盡快的修復(fù)吧。
以上就是MySQL 發(fā)生同步延遲時(shí)Seconds_Behind_Master還為0的原因的詳細(xì)內(nèi)容,更多關(guān)于MySQL 同步延遲Seconds_Behind_Master為0的資料請關(guān)注腳本之家其它相關(guān)文章!
- 詳解MySQL的Seconds_Behind_Master
- python3文件復(fù)制、延遲文件復(fù)制任務(wù)的實(shí)現(xiàn)方法
- docker實(shí)現(xiàn)mysql主從復(fù)制的示例代碼
- MySQL數(shù)據(jù)庫 Load Data 多種用法
- MySQL數(shù)據(jù)庫Shell import_table數(shù)據(jù)導(dǎo)入
- Mysql數(shù)據(jù)庫的主從同步配置
- Mysql實(shí)現(xiàn)簡易版搜索引擎的示例代碼
- MySQL命令無法輸入中文問題的解決方式
- 當(dāng)面試官問mysql中char與varchar的區(qū)別
- MySQL的從庫Seconds_Behind_Master延遲總結(jié)
相關(guān)文章
Mysql?刪除重復(fù)數(shù)據(jù)保留一條有效數(shù)據(jù)(最新推薦)
這篇文章主要介紹了Mysql?刪除重復(fù)數(shù)據(jù)保留一條有效數(shù)據(jù),實(shí)現(xiàn)原理也很簡單,mysql刪除重復(fù)數(shù)據(jù),多個(gè)字段分組操作,結(jié)合實(shí)例代碼給大家介紹的非常詳細(xì),需要的朋友可以參考下2023-02-02史上最簡單的MySQL數(shù)據(jù)備份與還原教程(中)(三十六)
這篇文章主要為大家詳細(xì)介紹了史上最簡單的MySQL數(shù)據(jù)備份與還原教程中篇,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-10-10mysql ONLY_FULL_GROUP_BY設(shè)置sql_mode無效排查問題(windows)
這篇文章主要介紹了mysql ONLY_FULL_GROUP_BY設(shè)置sql_mode無效排查問題(windows),具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-09-09MySQL安裝與配置:手工配置MySQL(windows環(huán)境)過程
這篇文章主要介紹了MySQL安裝與配置:手工配置MySQL(windows環(huán)境)過程,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-12-12安裝使用Percona XtraBackup來備份恢復(fù)MySQL的教程
這篇文章主要介紹了安裝使用Percona XtraBackup來備份恢復(fù)MySQL的教程,文中的示例環(huán)境基于CentOS系統(tǒng),需要的朋友可以參考下2015-12-12