MySQL 本身通過 show slave status 提供了 Seconds_Behind_Master ，用于衡量主備之間的復制延遲，但是 今天碰到了一個場景，發現 Seconds_Behind_Master 為 0 ， 備庫的 show slave status 顯示IO/SQL 執行緒都是正常的 ， MySQL 的主庫上的變更卻長時間無法同步到備庫上，如果沒有人為干預，直到一個小時以后， MySQL 才會自動重連主庫，繼續復制主庫的變更，
影響范圍： MySQL ， Percona ， MariaDB 的所有版本，
雖然這種場景非常特殊，遇到的概率并不高，但是個人覺得有必要提醒一下使用 MySQL 的 DBA 們，通過對這個場景的分析，也有助于我們更加深入的理解 MySQL replication 重試機制，
一、重現步驟
搭建主備的復制，臨時斷開主庫的網路，并 kill 掉主庫 MySQL 的 binlog dump 執行緒，
此時觀察備庫的復制情況， show slave status 中：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
但是此時你把網路恢復以后，在主庫做任何變更，備庫都無法獲得資料更新了，而且備庫上的show slave status 顯示： IO 執行緒 SQL 執行緒一切正常，復制延遲一直是 0 ，
一切正常，普通的監控軟體都不會發現備庫有資料延遲，
二、原理分析
MySQL 的 Replication 是區別于其他資料庫很關鍵的地方，也是可擴展性和高可用的基礎，它本身已經非常智能化，只需要我們呼叫 Change Master 指定 Binlog 檔案名和偏移位置就可以搭建從主庫到備庫的復制關系，
MySQL 復制 執行緒 會自動將目前復制位置記錄下來，在主備復制中斷的時候自動連上主庫，并從上次中斷的位置重新開始復制，這些操作都是全自動化的，不需要人為的干預，這給了 MySQL DBA 帶來了很多便利，同時卻也隱藏了很多細節，
要真正的理解前面問題的真相以及怎么解決這個問題，我們還是需要真正的理解 MySQL 復制的原理，
2.1“推”還是“拉”
首先， MySQL 的復制是“推”的，而不是“拉”的，“拉”是指 MySQL 的備庫不斷的回圈詢問主庫是否有資料更新，這種方式資源消耗多，并且效率低，“推”是指 MySQL 的主庫在自己有資料更新的時候推送這個變更給備庫，這種方式只有在資料有變更的時候才會發生互動，資源消耗少，如果你是程式員出身，你一定會選擇“推”的方式，
那么 MySQL 具體是怎么“推”的列，實際上備庫在向主庫申請資料變更記錄的時候，需要指定從主庫Binlog 的哪個檔案 ( MASTER_LOG_FILE ) 的具體多少個位元組偏移位置 ( MASTER_LOG_POS ) ，對應的，主庫會啟動一個 Binlog dump 的執行緒，將變更的記錄從這個位置開始一條一條的發給備庫，備庫一直監聽主庫過來的變更，接收到一條，才會在本地應用這個資料變更，
2.2 原因決議
從上面的分析，我們可以大致猜到為什么 show slave status 顯示一切正常，但是實際上主庫的變更都無法同步到備庫上來：
出現問題的時候， Binlog dump 程式被我們 kill 掉了，作為監聽的一方，備庫一直沒有收到任何變更，它會認為主庫上長時間沒有任何變更，導致沒有變更資料推送過來，備庫是無法判斷主庫上對應的Binlog dump 執行緒 到底是意外終止了，還是長時間沒有任何資料變更的，所以，對這兩種情況來說，備庫都顯示為正常，
當然， MySQL 會盡量避免這種情況，比如：
l 在 Binlog dump 被 kill 掉時通知備庫 執行緒 被 kill 掉了，所以我們重現時需要保證這個通知發送不到備庫，也就是說該問題重現的關鍵在于 Binlog dump 被 kill 的訊息由于網路堵塞或者其他原因無法發送到備庫，
l 備庫如果長時間沒有收到從主庫過來的變更，它會每隔一段時間重連主庫，
2.3 問題避免
基于上面的分析，我們知道 MySQL 在這種情況下確實無法避免，那么我們可以有哪些辦法可以避開列：
1. 被動處理：修改延遲的監控方法，發現問題及時處理，
2. 主動預防：正確設定 --master-retry-count ， --master-connect-retry ， --slave-net-timeout 復制重試引數，
l 被動處理
MySQL 的延遲監控大部分直接采集 show slave status 中的 Seconds_Behind_Master ，這種情況下，Seconds_Behind_Master 就無法用來真實的衡量主備之間的復制延遲了，我們建議通過在主庫輪詢插入時間資訊，并通過復制到備庫的時間差來獲得主備延遲的方案， Percona 提供了一種類似的方案 pt-heartbeat（在master上部署，實施監控從的延遲） ，
發現這個問題以后，我們只需要 stop slave; start slave; 重啟復制就能解決這個問題，
l 主動預防
MySQL 可以指定三個引數，用于復制執行緒重連主庫： --master-retry-count ， --master-connect-retry ， --slave-net-timeout ，
其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主備復制時指定，而slave-net-timeout 是一個全域變數，可以在 MySQL 運行時在線設定，
具體的重試策略為：備庫過了 slave-net-timeout 秒還沒有收到主庫來的資料，它就會開始第一次重試，然后每過 master-connect-retry 秒，備庫會再次嘗試重連主庫，直到重試了 master-retry-count 次，它才會放棄重試，如果重試的程序中，連上了主庫，那么它認為當前主庫是好的，又會開始 slave-net-timeout 秒的等待，
slave-net-timeout 的默認值是 3600 秒(mysql版本<= 5.7.6)， master-connect-retry 默認為 60 秒， master-retry-count默認為 86400 次，也就是說，如果主庫一個小時都沒有任何資料變更發送過來，備庫才會嘗試重連主庫，這就是為什么在我們模擬的場景下，一個小時后，備庫才會重連主庫，繼續同步資料變更的原因，
這樣的話，如果你的主庫上變更比較頻繁，可以考慮將 slave-net-timeout 設定的小一點，避免主庫Binlog dump 執行緒 終止了，無法將最新的更新推送過來，
當然 slave-net-timeout 設定的過小也有問題，這樣會導致如果主庫的變更確實比較少的時候，備庫頻繁的重新連接主庫，造成資源浪費，
查看設定情況：show variables like 'slave_net_timeout';
官網的默認配置：
| Property | Value |
|---|---|
| Command-Line Format | --slave-net-timeout=# |
| System Variable | slave_net_timeout |
| Scope | Global |
| Dynamic | Yes |
| Type | Integer |
| Default Value (>= 5.7.7) | 60 |
| Default Value (<= 5.7.6) | 3600 |
| Minimum Value | 1 |
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/113102.html
標籤：MySQL