故障排查
背景調查：最近幾天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;
永久解決辦法
- 數據量過多是由於我們保存的歷史數據的時間過長，我們可以設置 歷史數據的保留時長，將該值設置的更短一些，這樣數據量也就隨着減少了。
- 擴大數據庫的儲存空間