sofast 2019-11-19
线上给某个表执行新增索引SQL, 然后整个数据CPU打到100%, 连接数暴增到极限, 最后导致所有访问数据库的应用都奔溃.
SQL如下:
ALTER TABLE `book` ADD INDEX `idx_sub_title` (`sub_title` ASC);
能看到什么?
'10063293', 'root', '10.0.0.1:35252', 'novel', 'Query', '50', 'Waiting for table metadata lock', 'ALTER TABLE `lemon_novel`.`book` \nADD INDEX `idx_sub_title` (`sub_title` ASC)' '10094494', 'root', '172.16.2.112:42808', 'novel', 'Query', '31', 'Waiting for table metadata lock', 'SELECT \n book_trend.book_id AS book_id,
很奇怪, 这两边都在等"Waiting for table metadata lock"
看下来下面的一些结论:
后来在阿里云上面还看到过他们特定写过类似的答疑.
阿里云建议主要是这样操作.
select concat('kill ',i.trx_mysql_thread_id,';') from information_schema.innodb_trx i, (select id, time from information_schema.processlist where time = (select max(time) from information_schema.processlist where state = 'Waiting for table metadata lock' and substring(info, 1, 5) in ('alter' , 'optim', 'repai', 'lock ', 'drop ', 'creat'))) p where timestampdiff(second, i.trx_started, now()) > p.time and i.trx_mysql_thread_id not in (connection_id(),p.id);
然而在我的场景, 上面的SQL并没有任何的进程输出.
不过上面给了一些思路, 现在我们主要是因为有东西占用着 table metadata lock, 导致当前所有的东西都没有执行.
show full processlist;
看一眼没什么卵用, 处理那两个奇怪的wait lock, 其他的都挺正常的.
那么, 看下现在谁占用着锁?
怎么看呢?
select * from information_schema.innodb_trx;
神奇了, 真有两个东西在占用锁.
那kill 了他们看看.
额, 解决了.
某个奇怪的程序开了查询或者奇怪的操作, lock了 table metadata, 之后连接一直都没有被释放, 导致以上各种问题.
现在的问题来了, 究竟是哪个程序或者哪个代码导致的呢?
抱歉, 我现在也还不知道...
理论上可以查, 但是上次去查的时候发现数据库显示的host对应机器的端口早就没东西了, 死无对证ing.
全文完.