记一次truncate导致的锁表处理

一个不是很大的表,由数据分析部门生成并用于业务。由于代码发了新版需要第一次运行,所以在业务低峰期让数据部门执行了,逻辑是先truncate再insert重建。由于一直以来都没问题,觉得不会出错。结果过一会儿悲剧了,告警来了,app首页空白。。。

这种牵一发而动全局的故障,基本都是mysql引起。先看现象:

  1. cpu不高,很平稳
  2. 慢查询正常
  3. 连接数很高

这种很可能是锁表。进去一看processlist果然,那个truncate卡在那里,然后一堆线程在wating for meta data lock...  kill后故障恢复,数据表改由delete清空

由这个例子讲一下:

  • 锁表或db hang的一个显著表现就是connection飙升,这是由于连接池的行为,查询无法返回就新开连接重查。严重时可以耗尽connection limit
  • truncate应慎重,它属于ddl,会lock table meta data,甚至可能由锁表升级为锁库
  • 业务错综复杂,首页的推荐居然依赖数据分析...... 所以有了开头那个app空白的尴尬。相关人当然已经被怼啦,哈哈
posted @ 2017-09-12 00:04  Els0n  阅读(8954)  评论(2编辑  收藏  举报