早上看监控发现页面无法展示,于是登陆zabbix server主机,发现 /data分区 %100
赶紧看下是因为什么数据导致的（其实我知道是因为zabbix历史表导致/data分区爆满的主要写一下处理的思路）
看下果然因为 history_uint表导致的,
登陆zabbix,因为是刚入职,不熟悉环境,所以需要查看/etc/zabbix/zabbix_server.conf文件找到需要的登陆信息
登陆数据库查看表大小,（由于之前工作用的是商业监控对zabbix不大熟悉,所以不要笑话我哦）
select table_name Tables,round(((data_length + index_length)/1024/1024/1024),2) "GB" from information_schema.TABLES where table_schema='zabbix';
##检查表
mysql> desc history_uint;
+--------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+---------------------+------+-----+---------+-------+
| itemid | bigint(20) unsigned | NO | MUL | NULL | |
| clock | int(11) | NO | | 0 | |
| value | bigint(20) unsigned | NO | | 0 | |
| ns | int(11) | NO | | 0 | |
+--------+---------------------+------+-----+---------+-------+
##发现是clock用的是时间戳
##由于/data分区已经是100%所以之前想根据时间戳信息删除,几乎是变的不大可能
尝试的执行如下命令
mysql> select min(clock) from history_uint; ##等了好久不出结果,哪我根据什么删啊,怎么删啊,突然一想是不是系统中海油什么东西可以删除的,果然发现binlog有3G多的空间,删除一个再说
##这会在看监控页面zabbix已经是可以监控了,但是空间依然紧张啊
##于是查看history_unit看看表的定义
show create table history_uintG; ##原来是分区表啊
##这就好办了执行drop操作来drop掉之前的分区
alter table history_uint drop partition p20180301;
这下子空间使用率下来了,后续需要做的工作是
1.写检查脚本定期删除过期的分区
2.表修改成压缩的格式
3.更改表的存储引擎比如说（TokuDB）
先写到这里吧,后期把工作做完会继续更新的