mysql之 誤用SECONDS_BEHIND_MASTER衡量MYSQL主備的延遲時(shí)間

鏈接：http://www.woqutech.com/?p=1116

MySQL 本身通過 show slave status 提供了 Seconds_Behind_Master ，用于衡量主備之間的復(fù)制延遲，但是今天碰到了一個(gè)場景，發(fā)現(xiàn) Seconds_Behind_Master 為 0 ， 備庫的 show slave status 顯示 IO/SQL 線程都是正常的 ， MySQL 的主庫上的變更卻長時(shí)間無法同步到備庫上。如果沒有人為干預(yù)，直到一個(gè)小時(shí)以后，MySQL 才會自動重連主庫，繼續(xù)復(fù)制主庫的變更。

影響范圍： MySQL ， Percona ， MariaDB 的所有版本。

雖然這種場景非常特殊，遇到的概率并不高，但是個(gè)人覺得有必要提醒一下使用 MySQL 的 DBA 們。通過對這個(gè)場景的分析，也有助于我們更加深入的理解 MySQL replication 重試機(jī)制。

   一、重現(xiàn)步驟

搭建主備的復(fù)制，臨時(shí)斷開主庫的網(wǎng)絡(luò)，并 kill 掉主庫 MySQL 的 binlog dump 線程。

此時(shí)觀察備庫的復(fù)制情況， show slave status 中：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Seconds_Behind_Master: 0

但是此時(shí)你把網(wǎng)絡(luò)恢復(fù)以后，在主庫做任何變更，備庫都無法獲得數(shù)據(jù)更新了。而且備庫上的show slave status 顯示： IO 線程 SQL 線程一切正常，復(fù)制延遲一直是 0 。

一切正常，普通的監(jiān)控軟件都不會發(fā)現(xiàn)備庫有數(shù)據(jù)延遲。

   二、原理分析

MySQL 的 Replication 是區(qū)別于其他數(shù)據(jù)庫很關(guān)鍵的地方。也是可擴(kuò)展性和高可用的基礎(chǔ)。它本身已經(jīng)非常智能化，只需要我們調(diào)用 Change Master 指定 Binlog 文件名和偏移位置就可以搭建從主庫到備庫的復(fù)制關(guān)系。

MySQL 復(fù)制 線程 會自動將目前復(fù)制位置記錄下來，在主備復(fù)制中斷的時(shí)候自動連上主庫，并從上次中斷的位置重新開始復(fù)制。這些操作都是全自動化的，不需要人為的干預(yù)。這給了 MySQL DBA 帶來了很多便利，同時(shí)卻也隱藏了很多細(xì)節(jié)。

要真正的理解前面問題的真相以及怎么解決這個(gè)問題，我們還是需要真正的理解 MySQL  復(fù)制的原理。

   2.1“推”還是“拉”

首先， MySQL 的復(fù)制是“推”的，而不是“拉”的?！袄笔侵?nbsp;MySQL 的備庫不斷的循環(huán)詢問主庫是否有數(shù)據(jù)更新，這種方式資源消耗多，并且效率低?！巴啤笔侵?nbsp;MySQL 的主庫在自己有數(shù)據(jù)更新的時(shí)候推送這個(gè)變更給備庫，這種方式只有在數(shù)據(jù)有變更的時(shí)候才會發(fā)生交互，資源消耗少。如果你是程序員出身，你一定會選擇“推”的方式。

那么 MySQL 具體是怎么“推”的列，實(shí)際上備庫在向主庫申請數(shù)據(jù)變更記錄的時(shí)候，需要指定從主庫Binlog 的哪個(gè)文件 ( MASTER_LOG_FILE ) 的具體多少個(gè)字節(jié)偏移位置 ( MASTER_LOG_POS ) 。對應(yīng)的，主庫會啟動一個(gè) Binlog dump 的線程，將變更的記錄從這個(gè)位置開始一條一條的發(fā)給備庫。備庫一直監(jiān)聽主庫過來的變更，接收到一條，才會在本地應(yīng)用這個(gè)數(shù)據(jù)變更。

   2.2 原因解析

從上面的分析，我們可以大致猜到為什么 show slave status 顯示一切正常，但是實(shí)際上主庫的變更都無法同步到備庫上來：

出現(xiàn)問題的時(shí)候， Binlog dump 程序被我們 kill 掉了。作為監(jiān)聽的一方，備庫一直沒有收到任何變更，它會認(rèn)為主庫上長時(shí)間沒有任何變更，導(dǎo)致沒有變更數(shù)據(jù)推送過來。備庫是無法判斷主庫上對應(yīng)的Binlog dump 線程 到底是意外終止了，還是長時(shí)間沒有任何數(shù)據(jù)變更的。所以，對這兩種情況來說，備庫都顯示為正常。

當(dāng)然， MySQL 會盡量避免這種情況。比如：

l  在 Binlog dump 被 kill 掉時(shí)通知備庫 線程 被 kill 掉了。所以我們重現(xiàn)時(shí)需要保證這個(gè)通知發(fā)送不到備庫，也就是說該問題重現(xiàn)的關(guān)鍵在于 Binlog dump 被 kill 的消息由于網(wǎng)絡(luò)堵塞或者其他原因無法發(fā)送到備庫。

l  備庫如果長時(shí)間沒有收到從主庫過來的變更，它會每隔一段時(shí)間重連主庫。

   2.3 問題避免

基于上面的分析，我們知道 MySQL 在這種情況下確實(shí)無法避免，那么我們可以有哪些辦法可以避開列：

1.  被動處理：修改延遲的監(jiān)控方法，發(fā)現(xiàn)問題及時(shí)處理。

2.  主動預(yù)防：正確設(shè)置 --master-retry-count ，  --master-connect-retry ，  --slave-net-timeout 復(fù)制重試參數(shù)。

l  被動處理

MySQL 的延遲監(jiān)控大部分直接采集 show slave status 中的  Seconds_Behind_Master 。這種情況下，Seconds_Behind_Master 就無法用來真實(shí)的衡量主備之間的復(fù)制延遲了。我們建議通過在主庫輪詢插入時(shí)間信息，并通過復(fù)制到備庫的時(shí)間差來獲得主備延遲的方案。 Percona 提供了一種類似的方案 pt-heartbeat 。

發(fā)現(xiàn)這個(gè)問題以后，我們只需要 stop slave; start slave; 重啟復(fù)制就能解決這個(gè)問題。

l  主動預(yù)防

MySQL 可以指定三個(gè)參數(shù)，用于復(fù)制線程重連主庫： --master-retry-count ，  --master-connect-retry ，  --slave-net-timeout 。

其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主備復(fù)制時(shí)指定，而 slave-net-timeout 是一個(gè)全局變量，可以在 MySQL 運(yùn)行時(shí)在線設(shè)置。

具體的重試策略為：備庫過了 slave-net-timeout 秒還沒有收到主庫來的數(shù)據(jù)，它就會開始第一次重試。然后每過 master-connect-retry 秒，備庫會再次嘗試重連主庫。直到重試了 master-retry-count 次，它才會放棄重試。如果重試的過程中，連上了主庫，那么它認(rèn)為當(dāng)前主庫是好的，又會開始 slave-net-timeout 秒的等待。

slave-net-timeout 的默認(rèn)值是 3600 秒， master-connect-retry 默認(rèn)為 60 秒， master-retry-count 默認(rèn)為86400 次。也就是說，如果主庫一個(gè)小時(shí)都沒有任何數(shù)據(jù)變更發(fā)送過來，備庫才會嘗試重連主庫。這就是為什么在我們模擬的場景下，一個(gè)小時(shí)后，備庫才會重連主庫，繼續(xù)同步數(shù)據(jù)變更的原因。

這樣的話，如果你的主庫上變更比較頻繁，可以考慮將 slave-net-timeout 設(shè)置的小一點(diǎn)，避免主庫Binlog dump 線程 終止了，無法將最新的更新推送過來。

當(dāng)然 slave-net-timeout 設(shè)置的過小也有問題，這樣會導(dǎo)致如果主庫的變更確實(shí)比較少的時(shí)候，備庫頻繁的重新連接主庫，造成資源浪費(fèi)。

沃趣科技的 Q Monitor 監(jiān)控中對主備復(fù)制的延遲監(jiān)控，并不是通過 Seconds_Behind_Master 來監(jiān)控主備的。它采用了類似于 pt-heartbeat 的方式對主備進(jìn)行復(fù)制延遲監(jiān)控。