故障排查
背景调查：最近几天zabbix告警信息总是报Zabbix agent on xxxxxxxxx is unreachable for 5 minutes 错误，开始没有留意，通过两天观察，发现报警时间是有规律的，每天的凌晨12点05分、早晨6点05分、中午12点05分、下午18点05分，发现每隔6小时进行一次告警。于是第一时间想到是不是有什么计划任务执行，通过查看计划任务，发现zabbix的数据备份刚好前面定的每6小时执行一次，再一看数据库信息，发现数据如此之多，一下就反应过来，是因为备份时候占用IO太高导致zabbix—serveri连接agent超时，导致的告警，再一看为啥数据备份会占用很高的IO，通过查看数据发现，没一两个月，zabbix库占用了20多G的磁盘，故进一步排除，发现是history表和history_uint数据太多导致磁盘占用过多。
通过上面的排除已经确定history、history_uint表数据过多，加之是一些不是特别重要的数据，故想着对起清理。
history_uint
该表存储的是监控项的无符号整型的数据。
该数据的保存时长，取决于在监控项设置的 历史数据保留时长。
history
这个表保存的是浮点型的。
像 history_str 等保存的是 字符型数据。这些都是我们在设置监控项的对应的信息类型决定的。
该数据的保存时长，取决于在监控项设置的 历史数据保留时长
解决办法
临时解决办法
针对这个问题，我们临时的解决办法就是，就删除 history_uint 和 history 的一些历史数据。
要删除history_uint里的数据，还需要注意一点，由于数据量比较多，建议分多个时间段进行删除，比如数据库里由2018年10月到2019年10月的数据，那么可以将里面的数据分成4个阶段进行删除，从2018年的10月份到2019年1月份，从2019年的1月份到2019年的4月份，这样可以避免一次性删除数据过多导致数据库的负载比较大。（或者可以使用limit 10000）
这里数据量没有那么多，比如我要删除2020-05-20之前的数据，那么这个时间对应的时间戳是1589904000，可以通过如下命令进行获取时间戳
# date -d "2020-05-20 00:00:00" +%s
1589904000
delete history_uint
# delete from history_uint where clock < 1589904000 LIMIT 10000;
delete history
# delete from history where clock < 1589904000 LIMIT 10000;
上面执行删除后，数据的存储空间是没有减少的，因为对于delete from table_name where xxx 带条件的删除，不管是innodb还是MyISAM都不会释放空间，需要进行OPTIMIZE TABLE操作，进行释放空间。
注意：在optimize table '表名' 运行过程中，MySQL会进行锁表。
# optimize table history_uint;
# optimize table history;
永久解决办法
- 数据量过多是由于我们保存的历史数据的时间过长，我们可以设置 历史数据的保留时长，将该值设置的更短一些，这样数据量也就随着减少了。
- 扩大数据库的储存空间