迁移zabbix引发的一次MySQL锁阻塞
2017-11-20 17:47
176 查看
整体迁移zabbix,备份数据库时发现history开头的表都很大(8GB+)。zabbix的数据存储机制让zabbix每小时对history*表进行统计,统计值(最大值、最小值、平均值)放到trends*表中。注:zabbix配置监控项时有历史数据保存时间、趋势数据保存时间两项,分别对应history*、trends*。
备份zabbix数据库,由于history*表很大,为了减轻备份压力和缩短迁移时间决定抛弃一部分历史数据(7天前的数据全部删掉).
1、根据表中clock字段,删除几张大表7天前的数据(类似这样的语句)。
mysql> delete from history_uint where clock<unix_timestamp(adddate(now(),-7));
mysql> delete from history where clock<unix_timestamp(adddate(now(),-7));
2、然后就是无尽的等待这个事务的完成,数据太多发现没有半天是删不完的,决定kill这个线程然后truncate这些表,放弃所有的历史数据(必尽还有每小时统计一次的趋势数据,不用担心)
mysql> show processlist;
mysql> kill 136765
mysql> truncate table history_uint
3、发现truncate表时没有之前快了,不是感觉变慢了而是根本就没有执行的感觉。查看一下线程状态,是这样的。
***************************26. row***************************
Id: 384238681
User: root
db: zabbix
Host: localhost
Command: Query
Time: 385
State: Waiting for table metadate lock
Info: truncate table history_uint
***************************27. row***************************
truncate在等待一个锁,除了这个线程,还有好几个insert 、select等待锁:
***************************29. row***************************
Id: 384163828
User: zabbix
db: zabbix
Host: localhost
Command: Query
Time: 379
State: Waiting for table metadate lock
Info: select min(clock) from history_unit where itemid=28041
***************************30. row******************************************************30. row***************************
Id: 384244861
User: zabbix
db: zabbix
Host: localhost
Command: Query
Time: 53
State: Waiting for table metadate lock
Info: insert into history_unit (itemid,clock,value,ns) values (27326,1431400946,724714852352,435254068) ... ... ... ...
***************************31. row***************************
4、发现这个现象,有种不好了感觉,为了蔡某大神。大神就是大神,果然专业,一看就知道问题所在了。
大神的意思是这样的:
truncate没有拿到mdl锁,MySQL在回滚delete回滚结束前持有mdl锁,truncate被锁后续insert被truncate锁(表锁),杀掉truncate就可以正常 insert、select,完成delete回滚,回滚完成后就可以truncate了。这是一种锁阻塞现象。
按照大神的意思操作,杀掉truncate线程,等待MySQL的delete回滚结束,然后truncate表,然后、然后就顺利完成了zabbix数据库迁移。
文章出处:http://www.xiaomastack.com/2015/05/14/mysql-lock/
备份zabbix数据库,由于history*表很大,为了减轻备份压力和缩短迁移时间决定抛弃一部分历史数据(7天前的数据全部删掉).
1、根据表中clock字段,删除几张大表7天前的数据(类似这样的语句)。
mysql> delete from history_uint where clock<unix_timestamp(adddate(now(),-7));
mysql> delete from history where clock<unix_timestamp(adddate(now(),-7));
2、然后就是无尽的等待这个事务的完成,数据太多发现没有半天是删不完的,决定kill这个线程然后truncate这些表,放弃所有的历史数据(必尽还有每小时统计一次的趋势数据,不用担心)
mysql> show processlist;
mysql> kill 136765
mysql> truncate table history_uint
3、发现truncate表时没有之前快了,不是感觉变慢了而是根本就没有执行的感觉。查看一下线程状态,是这样的。
***************************26. row***************************
Id: 384238681
User: root
db: zabbix
Host: localhost
Command: Query
Time: 385
State: Waiting for table metadate lock
Info: truncate table history_uint
***************************27. row***************************
truncate在等待一个锁,除了这个线程,还有好几个insert 、select等待锁:
***************************29. row***************************
Id: 384163828
User: zabbix
db: zabbix
Host: localhost
Command: Query
Time: 379
State: Waiting for table metadate lock
Info: select min(clock) from history_unit where itemid=28041
***************************30. row******************************************************30. row***************************
Id: 384244861
User: zabbix
db: zabbix
Host: localhost
Command: Query
Time: 53
State: Waiting for table metadate lock
Info: insert into history_unit (itemid,clock,value,ns) values (27326,1431400946,724714852352,435254068) ... ... ... ...
***************************31. row***************************
4、发现这个现象,有种不好了感觉,为了蔡某大神。大神就是大神,果然专业,一看就知道问题所在了。
大神的意思是这样的:
truncate没有拿到mdl锁,MySQL在回滚delete回滚结束前持有mdl锁,truncate被锁后续insert被truncate锁(表锁),杀掉truncate就可以正常 insert、select,完成delete回滚,回滚完成后就可以truncate了。这是一种锁阻塞现象。
按照大神的意思操作,杀掉truncate线程,等待MySQL的delete回滚结束,然后truncate表,然后、然后就顺利完成了zabbix数据库迁移。
文章出处:http://www.xiaomastack.com/2015/05/14/mysql-lock/
相关文章推荐
- ubuntu zabbix 迁移mysql到新硬盘
- 由一次mycat+mysql水平拆分集群问题引发的思考
- 一次由于字符集问题引发的MySQL主从同步不一致问题追查
- 记录一次mysql迁移数据至greenplum的过程
- 由一次自建库迁移到阿里云RDS引发的性能问题。
- 记一次MongoDB性能问题(从MySQL迁移到MongoDB)
- zabbix mysql 迁移总结
- mysql数据迁移后,打开网站提示500----一次由ip addr引发的血案
- 由一次mycat+mysql水平拆分集群问题引发的思考
- 记录一次阻塞引发的系统超时
- 记一次由PCI BAR配置不正确引发的硬盘IO调度io_schedule阻塞的经历
- mysql-zabbix数据库迁移
- 【MySQL】一次扩展平台引发的字符集调整
- 一次修改mysql字段类型引发的技术探究
- 10.zabbix学习笔记:记一次zabbix故障引发的排查过程
- 记一次MongoDB性能问题(从MySQL迁移到MongoDB)
- 一次TSM SERVER服务器物理位置迁移引发的备份失败
- 记一次 mysql 联合索引顺序引发的查询慢死的坑
- 从Linux系统磁盘空间不足引发的Zabbix服务器数据库迁移 推荐
- [mysql] 一次sql耗时高引发报警的分析和处理