【MySQL】IO thread和SQL thread的雙Yes假象的問題

一、首先討論一下哪些現象形成：IO thread和SQL thread的雙Yes假象的問題

①　正常shutdown 或者 kill mysqld

結果狀態單：

Slave_IO_Running: Connecting
        Slave_SQL_Running: Yes
            Last_IO_Errno: 2003

②　kill -9 mysqld 或者 reboot 服務器
結果狀態:有可能同①，也有多是雙Yes（我本身測試的是同①結果，看別人測的有的是雙yes）

③　臨時斷開主庫的網絡，並 kill 掉主庫 MySQL 的 binlog dump 線程

結果狀態單：

Slave_IO_Running: Yes
         Slave_SQL_Running: Yes

說明：
網絡恢復以後，binlog dump線程已不存在；
主庫有新的寫入，從庫沒法同步，可是I/O線程和SQL線程都是YES，SBM也沒有延遲

二、主從同步機制

主庫上記錄二進制日誌，也就是binlog日誌。
備庫將主庫的二進制日誌複製到其本地的中繼日誌中。首先，備庫會啓動一個工做線程，稱爲I/O線程，I/O線程跟主庫創建一個普通的客戶端鏈接，而後在主庫上啓動一個特殊的二進制轉存（Binglog Dump）線程，這個轉存線程會讀取主庫上的二進制日誌中事件，併發送給從庫的I/O線程；若是主庫沒有更新信息將進入休眠。
備庫的SQL線程執行最後一步，該線程從中繼日誌中讀取事件並在備庫執行，從而實現備庫數據的更新。

3 binlog‘推’仍是‘拉’

首先， MySQL 的複製是「推」的，而不是「拉」的。「拉」是指 MySQL 的備庫不斷的循環詢問主庫是否有數據更新，這種方式資源消耗多，而且效率低。「推」是指 MySQL 的主庫在本身有數據更新的時候推送這個變動給備庫，這種方式只有在數據有變動的時候纔會發生交互，資源消耗少。若是你是程序員出身，你必定會選擇「推」的方式。
那麼 MySQL 具體是怎麼「推」的列，實際上備庫在向主庫申請數據變動記錄的時候，須要指定從主庫Binlog 的哪一個文件 ( MASTER_LOG_FILE ) 的具體多少個字節偏移位置 ( MASTER_LOG_POS ) 。對應的，主庫會啓動一個 Binlog dump 的線程，將變動的記錄從這個位置開始一條一條的發給備庫。備庫一直監聽主庫過來的變動，接收到一條，纔會在本地應用這個數據變動。

4 緣由解析

從上面的分析，咱們能夠大體猜到爲何 show slave status 顯示一切正常，可是實際上主庫的變動都沒法同步到備庫上來：
出現問題的時候， Binlog dump 程序被咱們 kill 掉了。做爲監聽的一方，備庫一直沒有收到任何變動，它會認爲主庫上長時間沒有任何變動，致使沒有變動數據推送過來。備庫是沒法判斷主庫上對應的Binlog dump 線程究竟是意外終止了，仍是長時間沒有任何數據變動的。因此，對這兩種狀況來講，備庫都顯示爲正常。
固然， MySQL 會盡可能避免這種狀況。好比：
a.在 Binlog dump 被 kill 掉時通知備庫 線程 被 kill 掉了。因此咱們重現時須要保證這個通知發送不到備庫，也就是說該問題重現的關鍵在於 Binlog dump 被 kill 的消息因爲網絡堵塞或者其餘緣由沒法發送到備庫。
b.備庫若是長時間沒有收到從主庫過來的變動，它會每隔一段時間重連主庫。

5 問題避免

基於上面的分析，咱們知道 MySQL 在這種狀況下確實沒法避免，那麼咱們能夠有哪些辦法能夠避開：
（1） 被動處理：修改延遲的監控方法，發現問題及時處理。
（2） 主動預防：正確設置 --master-retry-count ，  --master-connect-retry ，  --slave-net-timeout 複製重試參數。

被動處理

MySQL 的延遲監控大部分直接採集 show slave status 中的 Seconds_Behind_Master。這種狀況下，Seconds_Behind_Master 就沒法用來真實的衡量主備之間的複製延遲了。咱們建議經過在主庫輪詢插入時間信息，並經過複製到備庫的時間差來得到主備延遲的方案。 Percona 提供了一種相似的方案 pt-heartbeat 。
發現這個問題之後，咱們只須要 stop slave; start slave; 重啓複製就能解決這個問題。

主動預防

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 秒， master-connect-retry 默認爲 60 秒， master-retry-count 默認爲 86400 次。也就是說，若是主庫一個小時都沒有任何數據變動發送過來，備庫纔會嘗試重連主庫。這就是爲何在咱們模擬的場景下，一個小時後，備庫纔會重連主庫，繼續同步數據變動的緣由。這樣的話，若是你的主庫上變動比較頻繁，能夠考慮將 slave-net-timeout 設置的小一點，避免主庫Binlog dump 線程 終止了，沒法將最新的更新推送過來。固然 slave-net-timeout 設置的太小也有問題，這樣會致使若是主庫的變動確實比較少的時候，備庫頻繁的從新鏈接主庫，形成資源浪費。