共计 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
正文完
星哥玩云-微信公众号