MySQL一个延迟案例

 

突然接到报警显示MySQL主从之间延迟过大,随后尽快到集群上面看看,进行排查。

首先我们查看延迟是由什么造成的,排查一遍过后发现不是网卡和从库机器的负载,那就要从其他地方来排除了

查看binlog日志发现binlog日志文件多并且还大:

由于binlog刷新过快,因此很快就写满一个文件,可以确定出来是由于写入量过大导致的问题。

大概有两种情况:

1、可能此时业务突然增高

2、ROW格式本身就能导致日志文件的增大。

排除第一种可能,所以我们就开始分析binlog日志来进行查看问题。

后来发现delete from table where id < 1000000 limit 100导致的,因为我的表里面含有TEXT大字段,每次delete都会把TEXT大字段带入binlog,进而导致binlog激增。

所以我们后来去掉上面的那种删除用法,采用结合order by语句保证limit的有效性。

我们看一下官方的说法

因此我们就能找出问题了,我这里是参考某位博主的方法来解决的,点击这里

转载于:https://www.cnblogs.com/FengGeBlog/p/10240673.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值