MYSQL異常處理日誌：主從庫同步延遲時間過長的分析

問題描述：

程序上表現爲對 主庫 更新操做以後，從 從庫 查詢數據沒發生改變。懷疑是主從庫同步延遲致使。上從庫查看主從同步狀態，發現Seconds_Behind_Master時間長達一千多秒。正常狀況下主從庫延時個十幾秒還能夠容忍，一千多秒顯然就有問題了麼。。。

 

問題分析：

咱們在一個MYSQL實例上建立了四五個Database，其中一個Database數據量和壓力都比較大，從 從庫的processlist能夠看到從庫在處理日誌時常常發生lock的情況，可是lock只是壓力大database爲什麼會影響到其餘database也延遲呢？

 

原來從庫是單線程處理同步日誌，也就是說不管多少個database都是經過一個線程去執行更新操做，因此主從庫同步延遲的時間不是針對database的，是針對一個MYSQL實例的。

 

 

那麼，爲什麼從庫在處理日誌時會發生lock的狀態呢？

 

通常咱們都將主從庫讀寫分離，主庫負責寫操做，從庫負責讀操做。而通常的web應用讀數據的操做要遠遠大於寫數據的量，因此咱們在主庫上幾乎看不到由於更新數據致使的lock。那麼從庫的lock怎麼發生的呢？

 

 

對MyISAM表的讀操做（加讀鎖），不會阻塞其餘進程對同一表的讀請求，但會阻塞對同一表的寫請求。只有當讀鎖釋放後，纔會執行其它進程的寫操做。
對MyISAM表的寫操做（加寫鎖），會阻塞其餘進程對同一表的讀和寫操做，只有當寫鎖釋放後，纔會執行其它進程的讀寫操做。

 

 

從上面能夠看出，咱們在select的時候默認是會阻塞寫請求的，當一個表數據量到達了千萬級別，那麼執行一個select頗有可能就會變得比較費勁，再加上必定的壓力，不斷地select操做，雖然讀數據不會受到影響，可是卻阻塞了從庫處理同步日誌的操做。久而久之。。。可想而知。。。

 

問題處理：

1.首先一個MYSQL實例不要建立太多database，不然一旦其中一個庫壓力大常常被鎖，會致使全部庫同步都延遲，你傷不起啊。。。

2.壓力較大的狀況下使用幾個從庫值得考量，若是使用多個從庫也是能夠適當緩解上面lock的狀況發生。