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的情況發生。 

本文轉自 小強測試幫 51CTO部落格，原文連結：http://blog.51cto.com/xqtesting/914451，如需轉載請自行聯系原作者