Zabbix運用していると悩むのがDBの肥大化。何がそんなにDB使ってるのか把握したいとこですが、今回改善方法をブログします。別でRDS使ってもじゃんじゃん肥大化するので、なるべく監視サーバはコスト削減したいところです。となるとDBはサーバ内で管理するのが無難！
環境
- zabbix3.0
- MySQL5.7
/var/lib/mysql
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# du -h --max-depth=1 /var/lib/mysql | sort -nr 676K /var/lib/mysql/sys 32G /var/lib/mysql 31G /var/lib/mysql/zabbix 12M /var/lib/mysql/mysql 1.1M /var/lib/mysql/performance_schema [/var/lib/mysql/zabbix] # du -sh history.ibd 11G history.ibd [/var/lib/mysql/zabbix] # du -sh history_uint.ibd 19G history_uint.ibd |
historyがデカすぎ！
元々ディスクは50GBしかないので….zabbixサーバ構築時に管理>一般設定>データの保存期間をちゃんと設定しないと古いデータがそのまま残ってしまいます。
もちろん保存期間設定しなおしても古いデータが残るのでzabbixさんそこらへんうまいことやってほしいですね→Housekeeperで消えるそうです！それにDBについては定期的にフラグメント対策をしないと一生増え続けるので早急に対策をしましょう。
How to
以下のようにある期間だけhistory(グラフ)を残して以前のものは抹消するやり方が一番いいのかと思います。
1.zabbixのアクションを無効からのDBをダンプする(ここらへんはダンプスクリプトを作っておくべき)
2.zabbix serverを止める
|
1 |
# /etc/init.d/zabbix-server stop |
3.現テーブルをコピーして別テーブルで保存(1週間分)
timestampについては以下
https://www.epochconverter.com/
|
1 2 |
mysql> CREATE TABLE history_uint_new LIKE history_uint; mysql> INSERT INTO history_uint_new SELECT * FROM history_uint WHERE clock > 'xxxxxxxxxx'; |
4.コピーした別テーブルを現テーブルに移行
|
1 2 |
mysql> ALTER TABLE history_uint RENAME history_uint_old; mysql> ALTER TABLE history_uint_new RENAME history_uint; |
5.zabbix-server 起動
|
1 |
# /etc/init.d/zabbix-server start |
残りのテーブルも同様に。ちなみに3から4までスクリプトにしてみると以下になる。
- delete-tables-1month.sh
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#!/bin/sh MONTH=`date +%s`-2592000 for OLD_TABLE in `cat tables.list` do NEW_TABLE="${OLD_TABLE}_new" mysql -u root -pxxxxxxxxx --database=zabbix <<eof CREATE TABLE $NEW_TABLE LIKE $OLD_TABLE; INSERT INTO $NEW_TABLE SELECT * FROM $OLD_TABLE WHERE clock > $MONTH; DROP TABLE $OLD_TABLE; ALTER TABLE $NEW_TABLE RENAME $OLD_TABLE; eof done |
- tables.list
|
1 2 3 4 |
history_uint history trends_unit trends |
期間もコピーできない状態になってしまったら
|
1 2 3 4 5 6 7 8 9 10 11 |
mysql> TRUNCATE TABLE history_uint; Query OK, 0 rows affected (1.24 sec) mysql> TRUNCATE TABLE history; Query OK, 0 rows affected (0.85 sec) mysql> TRUNCATE TABLE trends; Query OK, 0 rows affected (0.08 sec) mysql> TRUNCATE TABLE trends_uint; Query OK, 0 rows affected (0.08 sec) |
上記のようにテーブルを空にします。空にするとグラフが消えるだけなので、監視には影響ありません。
DBのデフラグメント用スクリプトの準備
|
1 2 3 4 5 6 7 8 |
# cat db-defragmenting.sh #!/bin/sh mysql -u root -padachinpo --database=zabbix <<eof alter table history ENGINE=INNODB; alter table history_uint ENGINE=INNODB; alter table trends ENGINE=INNODB; alter table trends_uint ENGINE=INNODB; eof |
これをcronで1日一回仕込めばフラグメント対策はOK。
まとめ
これでDBの肥大化は心配なし！
参考
http://phucnw.blogspot.jp/2014/11/cleaning-up-zabbix-database.html
※追記
なんとTwitterでzabbixマスターさんにたくさんコメントを頂きました！
自動削除オンになっているんだが….謎すぎる。。
現在はちゃんと自動でディスク減らしてくれてます。
0件のコメント