Seconds_Behind_Master:In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.上面解釋了Seconds_Behind_Master這個值的真正含義，那么它的值到底是怎么計算出來的呢？官方解釋如下:Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind PRocessing the master binary log也就是說是SQL thread在執行IO thread獲取到的relay log的時間差。relay log中event記錄的是主庫上的時間戳，SQL thread執行的時間戳是從庫上的。實際上在binlog中每個binlog events都會附上執行時的timestamp，所以在在確定Seconds_Behind_Master的值時MySQL是通過比較當前系統的時間戳與當前SQL thread正在執行的binlog event的上的時間戳做比較，這個差值就是Seconds_Behind_Master的值。這樣的話在下面這些情況這個值就會不準確：1、主從服務器時間戳不一致；2、在主庫上執行了一個非常大的event，在這個event在主庫上沒執行完畢的時候，從庫的SBM會顯示為0，而當主庫執行完畢傳到從庫上開始執行的時候，就會顯示SBM非常巨大了；3、主從服務器之間網絡有明顯的延遲；手冊上對此也進行了說明：1、This time difference computation works even if the master and slave do not have identical clock times, provided that the difference,computed when the slave I/O thread starts, remains constant from then on. Any changes—including NTP updates—can lead to clock skews that can make calculation of Seconds_Behind_Master less reliable2、It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately. When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0; but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event. This is especially likely when the events have old timestamps; in such cases, if you execute SHOW SLAVE 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. MySQL的復制是推還是拉：“拉”是指 MySQL 的備庫不斷的循環詢問主庫是否有數據更新，這種方式資源消耗多，并且效率低。“推”是指 MySQL 的主庫在自己有數據更新的時候推送這個變更給備庫，這種方式只有在數據有變更的時候才會發生交互，資源消耗少。“推”存在一個問題：如果一段時間沒有數據推送，從庫如何去知道是因為主庫已經宕了還是真的這段時間沒有數據更新？比如說：當把主庫的binlog dump進程殺掉，這時候因為網絡異?；蛘咂渌驅е翨inlog dump 被kill的消息沒有發送到備庫。作為監聽的一方，備庫一直沒有收到任何變更，它會認為主庫上長時間沒有任何變更，導致沒有變更數據推送過來。備庫就無法判斷主庫上對應的Binlog dump 線程到底是意外終止了，還是長時間沒有任何數據變更的。問題避免：1、被動處理：修改主從延遲的監控方式，可以通過監控主機show master status/G的Position,和從執行show slave status/G的 Read_Master_Log_Pos（io_thread讀取主庫master_log_pos）和Exec_Master_Log_Pos（sql_thread執行主庫的master_log_pos）進行比較得出復制是否能跟上主的狀態。2、主動預防：正確設置 --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 設置的過小也有問題，這樣會導致如果主庫的變更確實比較少的時候，備庫頻繁的重新連接主庫，造成資源浪費。 IO thread和SQL thread的雙Yes假象的問題：1、正常shutdown，結果狀態雙no2、kill mysqld，結果狀態雙no3、kill -9 mysqld，結果狀態雙no
