早上看監控發現頁面無法展示,於是登陸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_uint\G; ##原來是分區表啊
##這就好辦了執行drop操作來drop掉之前的分區
alter table history_uint drop partition p20180301;
這下子空間使用率下來了,后續需要做的工作是
1.寫檢查腳本定期刪除過期的分區
2.表修改成壓縮的格式
3.更改表的存儲引擎比如說（TokuDB）
先寫到這里吧,后期把工作做完會繼續更新的