MySQL主從延時問題小計&個人總結

MySQL主從延時問題小計&個人總結

最近碰到幾次MySQL主從延時的問題，也有同行在抱怨這個，稍微整理一下

------------------------------------本文------------------------------------

出現問題的兩個情境：

情境1.主庫進行alter操作，花費大約10min，從庫複現這個alter的時候，也花費了約10min的時間，期間延時不斷在增加；

情境2.主庫上對一張MyISAM的表有大量的增刪改操作，從庫的業務語句在操作這張表經常會遇到表鎖，導致從庫延時；

情境問題分析：

情境1：其實這個情境很簡單，這種需要花費很多時間的alter語句，在主庫花費這麼久，在從庫複現必然也是要花費很多時間的，自然會阻塞之後的同步；

情境2：

首先要確認MyISAM的特性，MyISAM的表是表層級的鎖，讀寫互斥，

當同步的SQL線程在增刪改資料的時候，如果有select語句在操作這個表，是會產生表級鎖，阻塞同步的SQL線程，簡單類比以下表級鎖阻塞從庫SQL線程的情況

MyISAM的表遇到這種情況其實和情景1是一種類型的，那就是主庫上的操作在從庫複現的時候很慢/被阻塞，出現問題的地方都是複現的SQL本身，這種類型的問題，基本只能把這些“問題SQL”放在空閑時段去操作，屬於DBA的操作規範一類了，如果是正常時間段出現了這種情況，可以考慮單獨分離某一台延時的從庫，屏蔽業務請求，等延時消除以後，再添加回去，再替換另外有延時的從庫，依次去追主庫了；

主從延時還存在一種類型，就是從庫的同步卡在寫binlog這一部分，典型的表現就是從庫的系統IO等待很高，這種情況，視業務類型去修改事務組和日誌重新整理策略的值，或者更換儲存，提高硬體能力~

本文永久更新連結地址：