mysql怎么算延遲時間,mysql時間減時間

26 - MySQL備庫延遲幾小時？

上文中我們介紹了幾種可能導(dǎo)致備庫延遲的原因。你會發(fā)現(xiàn)，這些場景里，不論是偶發(fā)性的查詢壓力，還是備份，對備庫延遲的影響一般是分鐘級的，而且在備庫恢復(fù)正常以后都能夠追上來。

成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)的關(guān)注點不是能為您做些什么網(wǎng)站，而是怎么做網(wǎng)站，有沒有做好網(wǎng)站，給創(chuàng)新互聯(lián)建站一個展示的機會來證明自己，這并不會花費您太多時間，或許會給您帶來新的靈感和驚喜。面向用戶友好，注重用戶體驗，一切以用戶為中心。

但是，如果備庫執(zhí)行日志的速度持續(xù)低于主庫生成日志的速度，那這個延遲就有可能成了小時級別。而且對于一個壓力持續(xù)比較高的主庫來說，備庫很可能永遠都追不上主庫的節(jié)奏。

這就涉及到本文要介紹的話題：備庫并行復(fù)制能力。

談到主備的并行復(fù)制能力，我們要關(guān)注的是圖中黑色的兩個箭頭。一個箭頭代表了客戶端寫入主庫，另一箭頭代表的是備庫上 sql_thread 執(zhí)行中轉(zhuǎn)日志（relay log）。如果用箭頭的粗細來代表并行度的話，那么真實情況就如圖所示，第一個箭頭要明顯粗于第二個箭頭。

在主庫上，影響并發(fā)度的原因就是各種鎖了。由于 InnoDB 引擎支持行鎖，除了所有并發(fā)事務(wù)都在更新同一行（熱點行）這種極端場景外，它對業(yè)務(wù)并發(fā)度的支持還是很友好的。所以，你在性能測試的時候會發(fā)現(xiàn)，并發(fā)壓測線程 32 就比單線程時，總體吞吐量高。

而日志在備庫上的執(zhí)行，就是圖中備庫上 sql_thread 更新數(shù)據(jù) (DATA) 的邏輯。如果是用單線程的話，就會導(dǎo)致備庫應(yīng)用日志不夠快，造成主備延遲。

在官方的 5.6 版本之前，MySQL 只支持單線程復(fù)制，由此在主庫并發(fā)高、TPS 高時就會出現(xiàn)嚴重的主備延遲問題。

從單線程復(fù)制到最新版本的多線程復(fù)制，中間的演化經(jīng)歷了好幾個版本。接下來，我們來看看MySQL 多線程復(fù)制的演進過程。

說到底，所有的多線程復(fù)制機制，都是要把圖中只有一個線程的 sql_thread，拆成多個線程，也就是都符合下面的這個模型：

上圖中，coordinator 就是原來的 sql_thread, 不過現(xiàn)在它不再直接更新數(shù)據(jù)了，只負責讀取中轉(zhuǎn)日志和分發(fā)事務(wù)。真正更新日志的，變成了 worker 線程。而 work 線程的個數(shù)，就是由參數(shù) slave_parallel_workers 決定的。根據(jù)我的經(jīng)驗，把這個值設(shè)置為 8~16 之間最好（32 核物理機的情況），畢竟備庫還有可能要提供讀查詢，不能把 CPU 都吃光了。

接下來，你需要先思考一個問題：事務(wù)能不能按照輪詢的方式分發(fā)給各個 worker，也就是第一個事務(wù)分給 worker_1，第二個事務(wù)發(fā)給 worker_2 呢？

其實是不行的。因為，事務(wù)被分發(fā)給 worker 以后，不同的 worker 就獨立執(zhí)行了。但是，由于 CPU 的調(diào)度策略，很可能第二個事務(wù)最終比第一個事務(wù)先執(zhí)行。而如果這時候剛好這兩個事務(wù)更新的是同一行，也就意味著，同一行上的兩個事務(wù)，在主庫和備庫上的執(zhí)行順序相反，會導(dǎo)致主備不一致的問題。

接下來，請你再設(shè)想一下另外一個問題：同一個事務(wù)的多個更新語句，能不能分給不同的 worker 來執(zhí)行呢？

答案是，也不行。舉個例子，一個事務(wù)更新了表 t1 和表 t2 中的各一行，如果這兩條更新語句被分到不同 worker 的話，雖然最終的結(jié)果是主備一致的，但如果表 t1 執(zhí)行完成的瞬間，備庫上有一個查詢，就會看到這個事務(wù)“更新了一半的結(jié)果”，破壞了事務(wù)邏輯的隔離性。

所以，coordinator 在分發(fā)的時候，需要滿足以下這兩個基本要求：

mysql集群主從延遲時間怎么計算

主從復(fù)制延遲的監(jiān)測，我以前的做法是通過比較show slave statusG中的兩個變量的差值（Read_Master_Log_Pos，Exec_Master_Log_Pos），將差值設(shè)置為一個自己認為合理的范圍，Seconds_Behind_Master 沒有適用過，今天做一次解析:

Seconds_Behind_Master 是通過比較 SQL THREAD 接受 events事件的時間戳（timestamp） 與IO THREAD 執(zhí)行事件 events時間戳的差值--秒數(shù)來確定slave 落后于master多少。如果主從機器的時間不同，該時間的計算也是不會受影響的（如果時間發(fā)生異常，則這個秒數(shù)的就不怎么可靠啦）

如果slave SQL thread 或者 slave I/O thread 或者沒有連接到master，那么該變量的值為NULL.

0：表示master slave 復(fù)制沒有延遲（大部分情況下是這個樣子）。

正值：表示slave落后于master的秒數(shù)。

在網(wǎng)絡(luò)很快的情況下，I/O thread 能夠很快的從master上獲取binlog到slave的 relay-log。這種情況下， seconds_behind_master的值能真正代表slave落后于master的秒數(shù)。在網(wǎng)絡(luò)很差的情況下，I/O thread 同步很慢，slave收到的二進制日志信息，SQL THREAD能夠很快的執(zhí)行。這個時候 seconds_behind_master 是0，這種情況下 slave落后于master很多。

為了排除網(wǎng)絡(luò)的干擾，我們可以參考percona 的工具 pt-heartbeat.

該工具可以計算出MySQL復(fù)制或者是PostgreSQL,它可以更新master或者監(jiān)控復(fù)制。它還可以從my.cnf 讀取配置。它借助timestmp的比較實現(xiàn)的，首先需要保證主從服務(wù)器時間必須要保持一致，通過與相同的一個NTP server同步時鐘。它需要在主庫上創(chuàng)建一個heartbeat的表，里面的時間戳ts就是當前的時間戳 now()，該結(jié)構(gòu)也會被復(fù)制到從庫上。表建好以后，會在主庫上以后臺進程的模式去執(zhí)行一行更新操作的命令，定期去向表中的插入數(shù)據(jù)，這 個周期默認為1 秒，同時從庫也會在后臺執(zhí)行

mysql slave 備庫延遲是怎么得到的

在mysql的備庫的監(jiān)控中有一項很重要的指標:Seconds_Behind_Master,這個值是怎么得到的呢？下面從5.1.58的代碼中分析一下：

mysql的replication中有2個比較重要的class：Master_info(rpl_mi.h),

Relay_log_info(rpl_rli.h)，他們分別對應(yīng)于master,info文件和slave.info文件；很顯

然，Master_info是io_thread需要的，Relay_log_info是sql_thread需要的。Master_info中有一個變

量 clock_diff_with_master，這個值記錄著mysql的主庫和備庫的時間差，可以理解為主備的主機時間差。

分享題目：mysql怎么算延遲時間,mysql時間減時間
URL網(wǎng)址：http://muchs.cn/article16/hcpcdg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、定制網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、手機網(wǎng)站建設(shè)、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)