共计 521 个字符，预计需要花费 2 分钟才能阅读完成。
在某个业务的主库加完 2 个字段后，业务方反馈在 30 分钟后从库也一直无法查看到这个新字段。
在 slave 上执行 show slave status\G 如下图
show porcesslist; 如下图：
上图 2 张图，可以看到延迟较大，从库上的 alter 操作一直在等待 metadata lock，处于阻塞状态。
解决方法：
使用 SELECT * FROM information_schema.innodb_trx\G 找到那个事务未提交导致的问题:
kill2359; 杀掉这个线程即可。
杀完这个线程后，show slave status\G 主从延迟立马降了下来，show processlist 也没有持锁的状态了。【show slave status\G 即便是持锁，也就是短时间的 system lock】
如果我们使用了 zabbix 的 percona 监控的话，可以调整下相关触发器的阈值，如下图：
模板上默认是 100。一般只有 alter table 或者 select .. for update 这类的操作才会造成 LOCK，因此正常业务情况下 lock thread 超过 50 就需要关注下情况了。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-04/142692.htm
正文完
星哥玩云-微信公众号
