26 - MySQL備庫延遲幾小時(shí)？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mysql集群主從延遲時(shí)間怎么計(jì)算

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

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

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

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

正值：表示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收到的二進(jìn)制日志信息，SQL THREAD能夠很快的執(zhí)行。這個(gè)時(shí)候 seconds_behind_master 是0，這種情況下 slave落后于master很多。

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

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

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

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

mysql的replication中有2個(gè)比較重要的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中有一個(gè)變

量 clock_diff_with_master，這個(gè)值記錄著mysql的主庫和備庫的時(shí)間差，可以理解為主備的主機(jī)時(shí)間差。

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

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

廣告

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