「VACUUM FULL」と「pg_dumpでバックアップ、リストア」
zabbix 3.4 を使用しています。
history_log が 22GBとなっており、DB領域のディスク使用率も80%超え、
history_log のディスク使用量が削減したいと考えています。
Forum 内の事例をいろいろ確認しましたところ、方法としては、
VACUUM FULLを実施するか、pg_dump でバックアップを取得後リストアする方法がありました。
この二つの方法はメリットとデメリットは何でしょうか？
どちらの方法を選べばいいかの判断方法などはありますでしょうか。
(ちなみに、検索した中で、VACUUM FULLを実施する方法が多く上げられました。)
wakaba - 投稿数: 228
http://www.zabbix.jp/node/4548
で、ご返答させて頂いた通りですが、最大の違いはテーブルロックが掛かるかどうかです。
また、VACUUM FULLは削減出来てもINDEXは肥大化しますので、REINDEXが必要になる
場合もありますので、一長一短です
・ディスク容量を手っ取り早く開けたい場合
・頻繁に更新されていない参照オンリーに近いテーブル
などの場合、FULLは有効ですがそれ以外の場合は公式にも書かれている通り、FULL実行は
極力避けるのが無難というスタンスです。
公式は公式でしか無く、実運用ではケースバイケースなので最終的な判断はご自身でなされ
る以外の術は無いと思いますよ。
まぁ、あとはPostgreから離れますが、構築環境が仮想環境上＋LVM使っているならディスク
をオンラインで拡張は出来ますから、それで凌ぐって手も使えます。
データは貯めれば肥大化するものなので、計画を持って構築する必要がそもそもあるのでその
辺も改めてお考え下さい。
TNK - 投稿数: 4769
少しだけ追加させて頂きます。
両方のメリット：
・テーブル上の不要なレコードの削除が済んでいて、データベース
のファイル内の未使用の空き領域が大きくなっていれば作業後に
ディスクの使用率を下げることが期待できる。
両方のデメリット：
・不要なレコードの削除が済んでいなければ、ディスクの使用率を
下げることは期待できない。
・作業時間中はデータベースへのアクセスができない。
懸案事項：
・VACUUM FULLは元のデータベースと同じディスク上で処理が行わ
れるので、ディスクの使用率が80%を超えてしまっているのであ
れば、そのディスクを拡張しない限りVACUUM FULLは実行できな
いはず。
・ダンプを取得する場合は、ダンプ用のディスクを一時的にでも用
意してマウントしてダンプさせる必要がある。
・ダンプはネットワーク経由でもできるが処理速度に注意。
hellozabbix - 投稿数: 21
wakaba 様、TNK 様
お二人のコメント、ありがとうございます。
大変参考になりました。
1点だけ、確認したいですが、
>・ダンプを取得する場合は、ダンプ用のディスクを一時的にでも用
> 意してマウントしてダンプさせる必要がある。
pg_dumpを使うなら、ディスクも用意しなければいけないでしょうか？
以上、よろしくお願いいたします。
TNK - 投稿数: 4769
pg_dumpを使うならダンプするデータを置く場所の確保が必要です。
空きディスク領域がないのであれば、別途ディスクを用意する必要があります。
hellozabbix - 投稿数: 21
TNK 様
返信ありがとうございます。
別途ディスクを用意する必要がある点について、承知しました。
現状ではVACUUM FULLを実施しない方向に、pg_dump でバックアップを取得後リストアする方法を検討中です。
DB領域のディスク使用率は80%超えた(50GBのディスク容量のうち、42GBを使用)ため、
とりあえず100GBのディスクを追加&設定しましたところ、DB領域のディスク使用率が40%位まで減少(100GBの内、42GBを使用)
下記、不明点があるので、確認させてください。
1.zabbixのDB領域のディスク使用率推移を確認すると、偶にディスク使用率が減少しているように見えます。
(ディスク使用率が減少→しばらく増減なし→ディスク使用率が減少→ディスク使用率が徐々に増加)
保持期間などの変更は実施していない、housekeeperの動作でデータ量は減りますが、ディスク領域は
解放されず、空き容量が増えないと認識しているので、ディスク使用率が減少する原因は何でしょうか。
2.housekeeperの実施は、空き領域が残り何パーセントないとダメとか、そのような制約はありますか。
(「HousekeepingFrequency=1」、「MaxHousekeeperDelete=0」を設定しています。)
以上、よろしくお願いいたします。
TNK - 投稿数: 4769
PostgreSQLのすべての動作を把握しているわけではないので推測で
すが、処理をするために一時的にテンポラリファイルを作成して処
理しているのかもしれません。
対象のディスク内のファイルの増減や、各ファイルのサイズの変化
を確認してみてください。
処理しなければならないサイズ次第でしょう。
どのサーバーでも何パーセントならOKなどという基準はありません。
あと、基本的にhousekeeperが処理するのは削除処理なので、空き
領域が少なくても処理は行えるはずです。
懸念されるのは、サーバーの性能が低くてhousekeeperの処理が1時
間以内に終了していないということです。
Zabbixサーバーのログを確認して、1時間毎に削除処理が終了して
いるかを確認してみてください。
hellozabbix - 投稿数: 21
TNK 様
返信ありがとうございます。
>1.zabbixのDB領域のディスク使用率推移を確認すると、偶にディスク使用率が減少しているように見えます。
>
>PostgreSQLのすべての動作を把握しているわけではないので推測で
>すが、処理をするために一時的にテンポラリファイルを作成して処
>理しているのかもしれません。
>
>対象のディスク内のファイルの増減や、各ファイルのサイズの変化
>を確認してみてください。
対象のディスク内のファイルの増減や、各ファイルのサイズは多少増減していますが、
ディスク使用率の増減と合わないように見えます。
もしかしたらですが、下記は考えられないでしょうか。
今回は、DB高負荷が発生したため、その影響を受けて監視アラート件数が増大し、
DB領域のディスク使用率が増加しました。
その大量のアラートが、housekeeper によって削除し、
その後また大量のアラートが発生し、housekeeper によって削除するなら、
ディスク使用率が増減したりする可能性はありますか。
以上、よろしくお願いいたします。
TNK - 投稿数: 4769
ありえません。
housekeeperが削除するのは古いデータです。
直近に発生したイベントの情報をすぐに削除することはありません。
ファイルシステム上では、ファイルサイズきっかりだけ領域が確保
されるのではなく、ファイルシステム毎に設定されているブロック
単位でファイルシステム上の領域が確保されます。
ですので、単純にファイルサイズだけを足して計算できるものでは
ありません。
もしくは、増減しているファイルをすべて把握できていないのでは
ないでしょうか。
hellozabbix - 投稿数: 21
TNK 様
返信ありがとうございます。
>housekeeperが削除するのは古いデータです。
>直近に発生したイベントの情報をすぐに削除することはありません。
失礼しました。「大量のアラート」が発生した時期を書き忘れました。
「大量のアラート」は結構前(2018/11頃)に発生していました。それでもあり得ないでしょうか。
TNK - 投稿数: 4769
これまでの皆様の回答を読み返してみてください。
データベース上に登録したデータを削除しても、データベース用の
データファイルのサイズは減少しません。
hellozabbix - 投稿数: 21
TNK 様
返信ありがとうございます。
ご丁寧にありがとうございます。ディスク使用率について、理解しました。
また、追加で確認させてください。お願い申し上げます。
>懸念されるのは、サーバーの性能が低くてhousekeeperの処理が1時
>間以内に終了していないということです。
>Zabbixサーバーのログを確認して、1時間毎に削除処理が終了して
>いるかを確認してみてください。
1時間毎に削除処理が終了していない時に、再度housekeeperが実行される場合は
どうなりますか。
https://zabbix.org/wiki/Docs/specs/ZBXNEXT-207 を確認して、
「housekeeping procedure is already in progress」が出力されるようですが、
「housekeeping procedure is already in progress」が出力されることによって、何か起こりますか。
housekeeperの失敗か、それともリソースが減ったりしますか。
「housekeeping procedure is already in progress」で検索しても事例はあまりありませんでした。
ご回答いただきますようお願いいたします。
TNK - 投稿数: 4769
何も起こりません。
データの削除を継続し続けるだけです。
ただし、この状態が頻発したり継続したりするような場合は、きち
んとチューニングを行うことが必要です。
それでも改善しないのであれば、使用されているプラットフォーム
の性能不足であることが考えられますので、監視の内容を見直した
り、より高性能なプラットフォームへの移行を検討するなど、監視
の環境を見直してください。
hellozabbix - 投稿数: 21
TNK 様
返信ありがとうございます。
HouseKeeper処理について、再度確認させてください。お願いします。
housekeeperが削除するのはDBレコードって、
これはhousekeeperがDBに対して、DELETE(のみ)を実行して削除するという認識でいいでしょうか。
housekeeperがDBに対して、DROP DATABASE、TRUNCATEなどの処理は行っていない認識でいいでしょうか。
また、housekeeperがDBに対して、(オプションなどで)VACUUMを実行する処理も行っていない認識でいいでしょうか。
以上、よろしくお願いいたします。
TNK - 投稿数: 4769
やっていません。