记录一次Zabbix-server由于磁盘空间不足迁移数据库的过程

2017-11-22 14:28:20来源:http://chenx1242.blog.51cto.com/10430133/1983612作者:人点击

分享

今天登陆zabbix,发现zabbix-server磁盘已经超过了80%,发出了告警,如图:

登入服务器一看,使用#ll -Shil发现以下几个数据表太大了,占用了磁盘空间很多:

在mysql里查看也是这样(我的zabbix的databases就叫zabbix):

mysql>selecttable_name,(data_length+index_length)/1024/1024astotal_mb,table_rowsfrominformation_schema.tableswheretable_schema='zabbix';
+----------------------------+---------------+------------+
|table_name|total_mb|table_rows|
+----------------------------+---------------+------------+
|events|2876.00000000|23659702|
|history|3005.60937500|36816179|
|history_uint|2762.26562500|35895354|
|trends_uint|1189.60937500|16612396|
|trends|831.59375000|11548652|
+----------------------------+---------------+------------+
113rowsinset(0.08sec)

上面几个就是数据比较大的表,那么我们重点就是对他们开刀。由于数据量太大,按照普通的方式delete数据的话基本上不太可能。所以决定直接采用truncate table的方式来快速清空这些表的数据,再使用mysqldump导出数据,删除共享表空间数据文件,重新导入数据。

这个时候我们先停止zabbxi-server。

systemctlstopzabbix-server
systemctlstophttpd

然后登陆mysql,清除历史数据:

[root@js-online-zabbixserver~]#mysql-uroot-p
mysql>usezabbix;
Databasechanged
mysql>truncatetablehistory;
QueryOK,123981681rowsaffected(0.23sec)
mysql>optimizetablehistory;
1rowinset(0.02sec)
mysql>truncatetablehistory_uint;
QueryOK,57990562rowsaffected(0.12sec)
mysql>optimizetablehistory_uint;
1rowinset(0.03sec)

注意!如果在这一步,你先选择了delete,比如先删除了history_uint里7天之前的数据:

mysql>deletefromhistory_uintwhereclock<unix_timestamp(adddate(now(),-7));

但是你删了半天,发现数据量太大,这么删太慢了,又想到zabbix还有每小时统计一次的趋势数据,所以想干脆连7天的记录都不要了,于是查找并干掉了delete进程然后改用了truncate,如下:

mysql>showprocesslist;
mysql>kill136765
mysql>truncatetablehistory_uint

这样的话,你会发现truncate的速度很很慢的,就会很奇怪。答案其实不是truncate慢,而是直接死锁了!这个时候如果查看一下线程就会发现truncate正在等待insert 、select等等锁。

为什么会这样呢?是因为truncate没有拿到mdl锁,MySQL在回滚delete回滚结束前持有mdl锁,truncate被锁后续insert被truncate锁(表锁),杀掉truncate就可以正常 insert、select,完成delete回滚,回滚完成后就可以truncate了。这是一种锁阻塞现象。

这个时候就只能杀掉truncate线程,等待MySQL的delete回滚结束,然后重新去truncate表。

插播结束,现在可以对原有的数据库进行备份,#mysqldump -uroot -p密码 zabbix > /home/zabbix_db.sql 。

备份完毕之后,就可以# systecmtl stop mariadb关闭掉mysql,同时删除掉共享表空间数据文件,#rm -rf /var/lib/mysql/ib*。

然后准备一个空间比较大的盘,比如这个新磁盘就叫ZabbixDB,然后在里面建立一个DB文件夹。然后将/ZabbixDB/DB的所属组和用户都改成mysql,语句是:# chown -vR mysql:mysql /ZabbixDB/DB。

改完了之后再给予700权限:# chmod -vR 700 /etc/ZabbixDB/DB。

然后就把整个/var/lib/mysql*的内容都导入到ZabbixDB/DB里:#cp -av /var/lib/mysql* /ZabbixDB/DB。

修改my.cnf,在[mysqld]添加一句:innodb_file_per_table=1,这是修改InnoDB为独立表空间模式,每个数据库的每个表都会生成一个数据空间。同时也要修改数据库存放目录:

这个时候就可以# systemctl start mariadb重启mysql服务,启动完后查看一下刚刚在my.cnf里设置的“独立表空间”功能是否OK,检查语句是show variables like '%per_table%';,如果看到“ON”,就是说明已经开启了:

然后就可以还原数据库了:

[root@js-online-zabbixserverzabbix]#mysql-urootzabbix</home/zabbix_db.sql

如果这个时候报错,出现类似这样的错误:

这个可能是数据库缓存造成的,这个时候可以在数据库里使用FLUSH TABLES; ,不过这多半会不好使。

那么这个时候,就去新的mysql目录夹,即/ZabbixDB/DB,然后进入数据库zabbix,发现这个文件夹有很多文件,但是每一个文件都是既有一个.ibd又有一个.frm的,而这个“globalmacro”是只有ibd而没有.frm的,所以这个时候我们可以先把这个globalmacro.ibd转移到别的地方去,然后重新执行

#mysql-urootzabbix</home/zabbix_db.sql

还原数据库即可。

最后启动zabbix-server:

systemctlstartzabbix-server
systemctlstarthttpd

最后查看一下磁盘空间情况:

发现整个磁盘运行情况都OK了~,至此整个zabbix的数据库迁移完成。

[参考资料]https://stackoverflow.com/questions/17914446/mysqldump-problems-with-restore-error-please-discard-the-tablespace-before-imp

最后的最后,如果您觉得本文对您升职加薪有帮助,那么请不吝赞助之手,刷一下下面的二维码,赞助本人继续写更多的博文!


微信扫一扫

第七城市微信公众平台