MySQL中從庫(kù)延遲狀況排查的一則案例
今天給一個(gè)客戶巡檢的情況下發(fā)從庫(kù)沒(méi)有業(yè)務(wù)的情況mysqld的cpu的一個(gè)core占用100%.查主庫(kù)慢查詢也沒(méi)有關(guān)于寫(xiě)的SQL.
可以說(shuō)是典的單進(jìn)程復(fù)制把一個(gè)cpu占滿造成的.知道原因了,就好分析了.
分析一下binlog中寫(xiě)的什么,看看有什么地方可以優(yōu)化或是加速的.利用工具:pasrebinlog
利用show slave status\G; 查當(dāng)前同步的到節(jié)點(diǎn),然后對(duì)日值進(jìn)行解析.
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 ================================ ...
以最大的數(shù)排序看, 定位到: xx_db.xxtable,對(duì)于一個(gè)日值中能刪除10幾萬(wàn),寫(xiě)入10幾萬(wàn).是不是這個(gè)表寫(xiě)入比較慢了呢.
在從庫(kù)上查看innodb的相關(guān)情況:
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 這表已經(jīng)是表級(jí)表了,造成并發(fā)比較低,而且有大量的: GEN_CLUST_INDEX 而且屬于一個(gè)事務(wù). GEN_CLUST_INDEX表示沒(méi)有主建,內(nèi)部產(chǎn)生一個(gè)主建,對(duì)于內(nèi)部產(chǎn)生的主建很很容易造成page拆分的操作.
問(wèn)題到這里基本上可以得到解決問(wèn)題的方法了:
給xx_db.xxtable 添加一個(gè)主建即可.這里后是給xx_db.xxtable 添加了一個(gè)無(wú)業(yè)務(wù)意義的id int 自增主建.這樣立馬可以看到mysqld占用的cpu單核降到了3%左右, 同時(shí)后續(xù)同步一切正常,觀查一天沒(méi)出現(xiàn)同步延遲的問(wèn)題.
相關(guān)文章
Linux 安裝JDK Tomcat MySQL的教程(使用Mac遠(yuǎn)程訪問(wèn))
這篇文章主要介紹了Linux 安裝JDK Tomcat MySQL(使用Mac遠(yuǎn)程訪問(wèn)),本文圖文并茂給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2018-06-06MySQL如何從5.5升級(jí)到8.0(使用命令行升級(jí))
最近為了解決mysql低版本的漏洞,這篇文章主要給大家介紹了關(guān)于MySQL如何從5.5升級(jí)到8.0的相關(guān)資料,主要使用的命令行升級(jí),文中通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2023-03-03wampserver下mysql導(dǎo)入數(shù)據(jù)庫(kù)的步驟
這篇文章主要介紹了wampserver下mysql導(dǎo)入數(shù)據(jù)庫(kù)的步驟,需要的朋友可以參考下2016-08-08