日韩国产精品99成人不卡在线无毒|狠狠躁夜夜爽一级二级精品|亚洲日日噜噜孕妇中文字幕|日韩久草中文三级片

Seconds_behind_master反復(fù)橫跳？

   今天在線上遇到了一個MySQL的問題，這里記錄一下。

場景：

1、監(jiān)控報警某個業(yè)務(wù)的從庫有延遲

2、show slave status查看seconds_behind_master值反復(fù)在0、500、0、500、0、500之間跳動。

seconds_behind_master下面簡稱SBM。

    這種問題，更多的是先從官方文檔上去查看一些蛛絲馬跡。

    SBM的具體意思，想必大家都知道，它是指主從復(fù)制的SQL線程落后于主庫binlog的時間（也就是從庫的relay-log中的時間）。

在官方文檔上，找到一句話：

It is also possible that transient values for Seconds_Behind_Source may not reflect the situation accurately. When the replication SQL (applier) thread has caught up on I/O, Seconds_Behind_Source displays 0; but when the replication I/O (receiver) thread is still queuing up a new event, Seconds_Behind_Source may show a large value until the replication applier thread finishes executing the new event. This is especially likely when the events have old timestamps; in such cases, if you execute SHOW REPLICA STATUS several times in a relatively short period, you may see this value change back and forth repeatedly between 0 and a relatively large value.

鏈接：https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html

    這不就是我們遇到的情況嘛。

    這段話翻譯過來就是：在一些場景下，SBM的瞬時值并不能反映準(zhǔn)確的情況。當(dāng)復(fù)制的SQL線程追趕上IO線程的時候，這個值顯示為0；當(dāng)復(fù)制IO在等待新的事件的時候，SBM值顯示為一個較大的值，直到復(fù)制線程執(zhí)行完了這個新的event。而這種情況在某個事件具有舊的時間戳的時候，經(jīng)常容易發(fā)生。在這種情況下，你就會看到SBM值在0和一個較大的值之間反復(fù)橫跳。

    有了上述的理論基礎(chǔ)，我們來看我們的真實情況：

先來看主庫上真實的binlog位置：

show master statusG
*************************** 1. row ***************************
             File: mysql-bin.004718
         Position: 841616814
     Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

可以看到，主庫的binlog是4718這個號。

再來看下從庫復(fù)制的主庫位置：

show slave statusG
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.xx.xx.xx
                  Master_User: replica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.004717
          Read_Master_Log_Pos: 353151416
               Relay_Log_File: relay-bin.002983
                Relay_Log_Pos: 353151460
        Relay_Master_Log_File: mysql-bin.004717
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
          Exec_Master_Log_Pos: 353151301
              Relay_Log_Space: 353151781

可以看到，從庫復(fù)制的主庫binlog編號是4717.

當(dāng)前這種情況，就是從庫的IO線程比較慢，復(fù)制的主庫的binlog不是最新的binlog，而是上一個binlog，自然而然就帶有了這個老舊的時間戳。所以從庫的IO線程在排隊等待某個事務(wù)中的新事件的時候，就使得SBM值變?yōu)橐粋€比較大的數(shù)字，（500s）。然后等到復(fù)制SQL線程追上IO線程的時候，這個SBM的值又變成了0.

以上猜測，在實際分析binlog的時候，也被證明了。當(dāng)前的從庫的relay log中，確實有很多超級大的insert操作，而且從庫的relay log中的時間戳，記錄的時間基本都是當(dāng)前從庫時間9分鐘以前，恰好500s左右。

    關(guān)于SBM值，還有幾點需要說明：

1、在從庫忙的時候，SBM記錄的是從庫時間戳和來自主庫的binlog中的時間戳之間的差異

2、當(dāng)從庫空閑時，如果I/O和SQL線程狀態(tài)雙Yes，SBM=0，如果有任意一個線程狀態(tài)不為Yes，SBM=NULL

3、假設(shè)主從服務(wù)器時間戳不一致，如果從庫復(fù)制線程啟動之后，沒有做過任何時間變更，那么SBM的值也可以正常計算，但是如果修改了從庫或者主庫的時間，則可能導(dǎo)致時鐘偏移，從而導(dǎo)致這個計算值不可靠 

4、如果從庫上有人為寫入新數(shù)據(jù)，則可能導(dǎo)致SBM的值隨機(jī)波動。

5、在網(wǎng)絡(luò)條件較差的環(huán)境下，如果IO 線程延時嚴(yán)重，即使SBM的值為0，也不能說明主從之間沒有延遲。