mysqldump引发的故障

凌晨时分,  生产报警,  有台计划任务机器说, 堵了很多进程在那里

然后看了下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