凌晨时分, 生产报警, 有台计划任务机器说, 堵了很多进程在那里
然后看了下cpu, strace 了一下, 没发现问题, 都是sleep状态在等返回; 等什么呢, 后来翻到是 MySQL卡住了
MySQL 里面 show processlist 发现了大量的
'Waiting for table level lock' 的进程; 而且出现在不同的表上; 马上 google 了一下, 有几篇文章说, 把带 '/*!40001 SQL_NO_CACHE */' 关键字的进程kill掉就好
遂马上查了下, 还真有, 这里截了一段
Query 4402 Writing to net SELECT /*!40001 SQL_NO_CACHE */ * FROM `xxxxxx`
这是 select 整张表出来...
当然先kill了再说, 杀死了马上就恢复了
查原因
1. 凭感觉, 有人在 dump数据, 所以问了一下, 故障时间点, 谁在操作
2. 后来确认, 有个同事在用 mysqldump 导整个库
3. 是的, mysqldump 有个坑爹的参数, 默认是开启的...--lock-tables, 默认是开启的;; dump数据的时候参数没写好的话, 全个库的表都加锁了;; 这也解释了, 为什么把那一句kill掉以后, 就恢复了
-l, --lock-tables Lock all tables for read. (Defaults to on; use --skip-lock-tables to disable.)
教训
1. 权限控制没有控制好, dump库这种事情应该只能由少部分人操作
2. 其实这次kill对了语句是靠感觉和运气的... 正确的姿势应该是查谁锁住这些表了, 例如用下面这些语句
show open tables from database;
show engine innodb status\G;
PS: DBA经验值up
