Zabbixのデータクリーニング

ディレクトリ

一連の操作のZabbixのデータのクリーンアップ
- まず、問題
- 第二に、ソリューション

一連の操作のZabbixのデータのクリーンアップ

基本情報：

Zabbixのバージョン4.0.9

MySQLバージョン5.5

まず、問題

私たちは、意志Zabbixのテスト環境（アリクラウド）に保存されたRDSデータのが、RDSは、ストレージの唯一の10Gを買うとき、その数ヶ月のない監視がありません、彼らはストレージ容量の警告の不足を報告し、当社のデータベース。

それは、テーブルを占めていたより多くの記憶領域である第一の調査、私たちは、主にすることを見つけるhistoryと、history_uint二つのテーブル。スペースは最大であるhistory_uintテーブル。

次に、2つのテーブルは、どのようなことに格納されていますか？

history_uint

このテーブルは、監視項目符号なし整数データが格納されています。

あなたは、長期保存の設定を監視し、過去のデータに応じて、データ長を保存します。

CREATE TABLE `history_uint` (
  `itemid` bigint(20) unsigned NOT NULL,
  `clock` int(11) NOT NULL DEFAULT '0',
  `value` bigint(20) unsigned NOT NULL DEFAULT '0',
  `ns` int(11) NOT NULL DEFAULT '0',
  KEY `history_uint_1` (`itemid`,`clock`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

アイテムID、アイテムID監視されています
タイムスタンプの時刻データ（UNIX）
値は、監視項目のデータの値であり、
NSナノ秒の時間値（1Sの値よりも小さいです）

コレクションアイテムの正確なリアルタイムのモニタリングは、クロック+ NSによって構成されています。

歴史

このテーブルには、浮動小数点型に格納されています。

同様にhistory_str、その他の文字データが格納されています。これらは、私たちが意思決定の種類に対応した監視情報を設定する項目です。

あなたは、長期保存の設定を監視し、過去のデータに応じて、データ長を保存します。

スプレッド

テーブルは、trendsトレンドデータに格納され、履歴トレンドテーブルのみを保持し、異なるされる
平均値が小さいです。したがって、テーブルの多くの種類、対応する歴史は傾向があります。

第二に、ソリューション

一時的な解決策

この問題に対処するために、我々は一時的な解決策を削除することである必要がありhistory_uintかつhistoryいくつかの過去のデータ。

例えば、タイムスタンプを取得する最初の時間を削除するには、我々は前に2019年9月10 11:00データを削除したいです。そこで、今回は、スタンプがある時間に対応します1568084400。

私たちは、削除history_uint、その後、言葉よりも我々のデータは、我々は2018年10月に、このような2019年10月からデータベース内の我々のデータなど、いくつかの期間で削除することを提案している場合は、ここで注意することは、ポイントでデータを我々は、4つの段階にデータがデータ比較データベースを削除するため、一回に過大な負荷リードを避け、2018年10月から2019年1月に、2019年1月から2019年4月に、削除することができます内側に大規模な。（あるいは限界10000を使用してもよいです）

history_uintを削除

delete  from history_uint  where  clock < 1568084400  LIMIT 10000;

履歴を削除

delete  from history  where  clock < 1568084400  LIMIT 10000;

上記削除操作の実装が完了した後、我々は非常に珍しいことが起こりました。

あまりにも多く、私たちはデータを削除しますが、データ・ストレージ・スペースが減少しないこと。しかし、（これは新しく追加されたデータによるものではないアリ雲が正しくないと表示されるの後ろに、つながっ）増加しました。

その理由は次のとおりです。

削除のための条件とのxxxは、それがあるかどうかTABLE_NAMEから削除するinnodbか、MyISAMディスク領域を解放しません。

なぜ50人が会社を去ったときたとえば、100局と、同社は、100人は、座って？減少するが、そのステーションは、まだそこに唯一のステーションが削除されることはありません場所のスペースを削除します存在しないだろう、彼らは駅に設置することができますが、新たにスタッフを募集しています。

だから我々はする必要がOPTIMIZE TABLEスペースを解放、操作すること。

注意：optimize table '表名'操作中に、MySQLテーブルをロックします。

OPTIMIZE TABLE history_uint;
OPTIMIZE TABLE history;

RDSの操作が完了した後、我々はおそらくコンソールに保存されている私たちの実際の情報を見るために数分を必要としています。

コンテンツ上に描画：https://blog.csdn.net/weixin_40596063/article/details/82978736

1、drop table table_name 立刻释放磁盘空间 ，不管是 Innodb和MyISAM ，不保留表结构，;

2、truncate table table_name 立刻释放磁盘空间 ，不管是 Innodb和MyISAM 。truncate table保留表结构，删除方式类似drop table;

3、delete from table_name删除表的全部数据,对于MyISAM 会立刻释放磁盘空间 ,InnoDB 不会释放磁盘空间;

4、对于delete from table_name where xxx带条件的删除, 不管是innodb还是MyISAM都不会释放磁盘空间;

5、对于delete操作（或带条件的delete）需要释放空间，在delete以后使用optimize table table_name 会立刻释放磁盘空间。不管是innodb还是myisam ；所以要想达到释放磁盘空间的目的，delete以后执行optimize table 操作。

スペースのために後の未発表の削除。新しいスペースを開放する必要なしに挿入する場合。私たちは予約スペースを使用します。

恒久的な解決策

データの量は、我々はあまりにも多くの履歴データを保存する時間に起因して長すぎるデータ、それの量を低減するように、我々は、過去のデータを保持する時間の長さを設定短くなるように、この値を設定することができます。
データベースのストレージスペースを展開します。