首页 / Mysql / MySQL中从库延迟状况排查的一则案例

MySQL中从库延迟状况排查的一则案例

今天给一个客户巡检的情况下发从库没有业务的情况mysqld的cpu的一个core占用100%.查主库慢查询也没有关于写的SQL.
可以说是典的单进程复制把一个cpu占满造成的.知道原因了,就好分析了.
分析一下binlog中写的什么,看看有什么地方可以优化或是加速的.利用工具:pasrebinlog
利用show slave statusG; 查当前同步的到节点,然后对日值进行解析.

今天给一个客户巡检的情况下发从库没有业务的情况mysqld的cpu的一个core占用100%.查主库慢查询也没有关于写的SQL.
可以说是典的单进程复制把一个cpu占满造成的.知道原因了,就好分析了.
分析一下binlog中写的什么,看看有什么地方可以优化或是加速的.利用工具:pasrebinlog
利用show slave statusG; 查当前同步的到节点,然后对日值进行解析.

 

以最大的数排序看, 定位到: xx_db.xxtable,对于一个日值中能删除10几万,写入10几万.是不是这个表写入比较慢了呢.
在从库上查看innodb的相关情况:

从Innodb 的monitor output 中也可看到 xx_db.xxtable 这表已经是表级表了,造成并发比较低,而且有大量的: GEN_CLUST_INDEX 而且属于一个事务.  GEN_CLUST_INDEX表示没有主建,内部产生一个主建,对于内部产生的主建很很容易造成page拆分的操作.

问题到这里基本上可以得到解决问题的方法了:
给xx_db.xxtable 添加一个主建即可.这里后是给xx_db.xxtable 添加了一个无业务意义的id int 自增主建.这样立马可以看到mysqld占用的cpu单核降到了3%左右, 同时后续同步一切正常,观查一天没出现同步延迟的问题.

本文来自网络,不代表我是攻城狮立场,转载请注明出处:https://www.54gcs.cn/sql/mysql/2225.html

helwo作者

上一篇
下一篇

为您推荐

发表评论

联系我们

联系我们

在线咨询: QQ交谈

邮箱: web@5vo.cn

工作时间:周一至周五,9:00-17:30,节假日休息
关注微信
微信扫一扫关注我们

微信扫一扫关注我们

手机访问
手机扫一扫打开网站

手机扫一扫打开网站

返回顶部
跳至工具栏