12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
ADADADADAD
mysql数据库 时间:2024-12-25 09:57:09
作者:文/会员上传
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
2017年4月1日星期六
在某个业务的主库加完2个字段后,业务方反馈在30分钟后从库也一直无法查看到这个新字段。在slave上执行show slave status\G 如下图
show porcesslist; 如
以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。
2017年4月1日星期六
在某个业务的主库加完2个字段后,业务方反馈在30分钟后从库也一直无法查看到这个新字段。
在slave上执行show slave status\G 如下图
show porcesslist; 如下图:
上图2张图,可以看到延迟较大,从库上的alter操作一直在等待metadata lock,处于阻塞状态。
解决方法:
使用SELECT*FROMinformation_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就需要关注下情况了。
11-20
11-19
11-20
11-20
11-20
11-19
11-20
11-20
11-19
11-20
11-19
11-19
11-19
11-19
11-19
11-19