MySQL中從庫延遲狀態排查的一則案例

MySQL中從庫延遲狀態排查的一則案例。本站提示廣大學習愛好者：（MySQL中從庫延遲狀態排查的一則案例）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL中從庫延遲狀態排查的一則案例正文

明天給一個客戶巡檢的情形下發從庫沒有營業的情形mysqld的cpu的一個core占用100%.查主庫慢查詢也沒有關於寫的SQL.
可以說是典的單過程復制把一個cpu占滿形成的．曉得緣由了，就好剖析了．
剖析一下binlog中寫的甚麼，看看有甚麼處所可以優化或是加快的．應用對象：pasrebinlog
應用show slave status\G; 查以後同步的到節點，然後對日值停止解析．

git clone https://github.com/wubx/mysql-binlog-statistic.git
cd mysql-binlog-statistic/bin/
parsebinlog /u1/mysql/logs/mysql-bin.000806

...
====================================
Table xx_db.xxtable:
Type DELETE opt： 101246
Type INSERT opt： 103265
================================
...

以最年夜的數排序看，　定位到:　xx_db.xxtable，關於一個日值中能刪除10幾萬，寫入10幾萬．是否是這個表寫入比擬慢了呢．
在從庫上檢查innodb的相干情形：

MySQL> show engine innodb status\G;
...
---TRANSACTION 1C0C2DFDF, ACTIVE 3 sec fetching rows
mysql tables in use 1, locked 1
3361 lock struct(s), heap size 407992, 477888 row lock(s), undo log entries 42
MySQL thread id 43, OS thread handle 0x7fc1800c4700, query id 1908504 Reading event from the relay log
TABLE LOCK table xx_db.xxtable trx id 1C0C2DFDF lock mode IX
RECORD LOCKS space id 1002 page no 1975 n bits 1120 index `AK_movieid` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6965 n bits 264 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6967 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6973 n bits 264 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6982 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6983 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6987 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6999 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 7000 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
TOO MANY LOCKS PRINTED FOR THIS TRX: SUPPRESSING FURTHER PRINTS
----------------------------
END OF INNODB MONITOR OUTPUT

...

從Innodb 的monitor output 中也可看到 xx_db.xxtable 這表曾經是表級表了，形成並發比擬低，並且有年夜量的：　GEN_CLUST_INDEX　並且屬於一個事務．　　GEN_CLUST_INDEX表現沒有主建，外部發生一個主建，關於外部發生的主建很很輕易形成page拆分的操作．

成績到這裡根本上可以獲得處理成績的辦法了：
給xx_db.xxtable 添加一個主建便可．這裡後是給xx_db.xxtable 添加了一個無營業意義的id　int　自增主建．如許立馬可以看到mysqld占用的cpu單核降到了3％閣下，　同時後續同步一切正常，不雅查一天沒湧現同步延遲的成績．