本文共 3288 字，大约阅读时间需要 10 分钟。
今天登陆zabbix，发现zabbix-server磁盘已经超过了80%，发出了告警，如图：
登入服务器一看，使用#ll -Shil发现以下几个数据表太大了，占用了磁盘空间很多：
在mysql里查看也是这样（我的zabbix的databases就叫zabbix）：
| 1 2 3 4 5 6 7 8 9 10 11 | mysql> select table_name, (data_length+index_length) /1024/1024 as total_mb, table_rows from information_schema.tables where table_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 | +----------------------------+---------------+------------+ 113 rows in set (0.08 sec) |
上面几个就是数据比较大的表，那么我们重点就是对他们开刀。由于数据量太大，按照普通的方式delete数据的话基本上不太可能。所以决定直接采用truncate table的方式来快速清空这些表的数据，再使用mysqldump导出数据，删除共享表空间数据文件，重新导入数据。
这个时候我们先停止zabbxi-server。
| 1 2 | systemctl stop zabbix-server systemctl stop httpd |
然后登陆mysql，清除历史数据：
| 1 2 3 4 5 6 7 8 9 10 11 | [root@js-online-zabbixserver ~] # mysql -uroot -p mysql > use zabbix; Database changed mysql > truncate table history ; Query OK, 123981681 rows affected (0.23 sec) mysql > optimize table history ; 1 row in set (0.02 sec) mysql > truncate table history_uint; Query OK, 57990562 rows affected (0.12 sec) mysql > optimize table history_uint; 1 row in set (0.03 sec) |
注意！如果在这一步，你先选择了delete，比如先删除了history_uint里7天之前的数据：
| 1 | mysql> delete from history_uint where clock<unix_timestamp(adddate(now(),-7)); |
但是你删了半天，发现数据量太大，这么删太慢了，又想到zabbix还有每小时统计一次的趋势数据，所以想干脆连7天的记录都不要了，于是查找并干掉了delete进程然后改用了truncate，如下：
| 1 2 3 | mysql> show processlist; mysql> kill 136765 mysql> truncate table history_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”，就是说明已经开启了：
然后就可以还原数据库了：
| 1 | [root@js-online-zabbixserver zabbix] # mysql -uroot zabbix < /home/zabbix_db.sql |
如果这个时候报错，出现类似这样的错误：
这个可能是数据库缓存造成的，这个时候可以在数据库里使用FLUSH TABLES; ，不过这多半会不好使。
那么这个时候，就去新的mysql目录夹，即/ZabbixDB/DB，然后进入数据库zabbix，发现这个文件夹有很多文件，但是每一个文件都是既有一个.ibd又有一个.frm的，而这个“globalmacro”是只有ibd而没有.frm的，所以这个时候我们可以先把这个globalmacro.ibd转移到别的地方去，然后重新执行
| 1 | # mysql -uroot zabbix < /home/zabbix_db.sql |
还原数据库即可。
最后启动zabbix-server:
| 1 2 | systemctl start zabbix-server systemctl start httpd |
最后查看一下磁盘空间情况：
发现整个磁盘运行情况都OK了~，至此整个zabbix的数据库迁移完成。
[参考资料]
最后的最后，如果您觉得本文对您升职加薪有帮助，那么请不吝赞助之手，刷一下下面的二维码，赞助本人继续写更多的博文！
本文转自 苏幕遮618 51CTO博客，原文链接:http://blog.51cto.com/chenx1242/1983612
转载地址：http://sicra.baihongyu.com/