mysql主從複製延遲問題

一.如何檢測主從延遲

     可以通過監控 showslave status\G 命令輸出的seconds_behind_master 參數值來判斷，是否存在主從延時。

     null -表示io_thread或sql_thread發生故障，也就是該線程的Running狀態是No。（有故障）
　　0-該值爲零，是我們極爲渴望看到的情況，表示主從複製良好，可以認爲lag不存在。（無延遲）
　　正值-表示主從已經出現延時，數字越大表示從庫落後主庫越多。（有延遲）
　　負值-幾乎很少見，只是聽一些資深的DBA說見過，其實這是一個BUG值，該參數是不支持負值的，也就是不應該出現。（BUG）

二.主從庫延遲產生的原因

    

 

    在分析延遲產生原因之前，我們先來熟悉一下主從同步的工作原理和步驟：

      步驟1： 所有數據更新都會被主庫記錄到主庫的二進制日誌（變更日誌）。

      步驟2： 從庫的IO線程從主庫上讀取二進制日誌，寫入到從庫的中繼日誌上。

      步驟3： 從庫的SQL線程讀取中繼日誌上的內容來更新從庫。

      到底是什麼原因導致了主從的延遲呢？問題無非出在這三個步驟的某個過程中，一般情況下，主庫對DDL和DML產生binlog和slave的Slave_IO_Running線程從主庫取日誌的效率都很高，問題可能會出在從庫的sql線程上，由於從庫的Slave_SQL_Running是單線程作業，不能併發執行，所以當主庫的TPS併發較高時，就容易產生延遲。

三.如何解決主從延遲

1. 保證主庫的DDL快速執行。

2. 還有就是主庫寫對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit =1之類的設置，而slave則不需要這麼高的數據安全，完全可以將sync_binlog設置爲0或者關閉binlog，innodb_flushlog也可以設置爲0來提高sql的執行效率。

3. 選擇支持多線程的mysql版本來進行主從複製，避免併發高峯時可能的延遲，mysql-5.6.3已經支持了多線程的主從複製。

4. 另外就是使用比主庫更好的硬件設備作爲slave。

註釋：innodb_flush_log_at_trx_commit默認值1的意思是每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬盤，這是很費時的。特別是使用電池供電緩存（Batterybacked upcache）時。設成2對於很多運用，特別是從MyISAM錶轉過來的是可以的，它的意思是不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值2只會在整個操作系統掛了時纔可能丟數據。