SystemManager Gのマネージャにおいてデータ蓄積量が想定外に大きくなりディスク容量が逼迫状態になった際に、PostgreSQLのデータ削除を行いディスク使用量を削減する手順を説明します。
SystemManager Gでは監視運用中に発生したメッセージ、収集した性能データなどのデータがPostgreSQL上に蓄積されますが、ディスク使用量が想定を上回ってしまった場合やそれによってディスク容量枯渇を引き起こした場合に、本手順を実施しPostgreSQLのディスク使用量を削減する必要があります。
SystemManager GがPostgreSQLを利用するにあたってPostgreSQL側のタイミングで自動バキューム(AUTO VACUUM)は実行されますが、自動バキュームの場合は削除済レコードのデータ領域はディスク使用量としては減ることはなく、PostgreSQL内で再利用される動作となっています。そのため再利用のために確保している領域を一度クリアして空きディスク容量として戻したい場合は、以降に記載するVACUUM FULLコマンドを実行する必要があります。
本手順を実施している間はSystemManger Gによる監視は行えず、またVACUUM FULLコマンドの実行には時間がかかる場合が多いです。そのため上述の通りディスク使用量が逼迫している状況でなければ本手順の実施は不要です。
以降の手順ではSystemManager Gのサービスのうち特にディスク使用量が多いサービスを対象に実施手順を説明します。
■事前準備
○各データベースのディスク消費量の確認
以降のデータ削除手順を実施する前に、PostgreSQL上で各SystemManager Gコンポーネントがどの程度ディスクを消費しているかご確認ください。
以下のコマンドを実行することで、各データベースのサイズを確認することができます。
以降の手順ではすべてPostgreSQLの待ち受けポートをデフォルトの5432として記載しています。設定変更されている場合は、環境に合わせて読み替えてください。
また以下のコマンドを実行するとpostgresユーザのパスワード入力を求められますので、環境に合わせて入力してください。
以下のコマンドは表示の都合により改行されている場合がありますが、実際には改行せずに1行で入力してください。
psql -p 5432 -U postgres -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;"
上記コマンドの出力結果のうち、データベース名(datnameカラム)が「msc_」で始まるものがSystemManager Gが使用しているデータベースです。
上記コマンドの出力結果から、サイズの大きいデータベースあるいは想定サイズを超過しているデータベースを対象に移行のデータ削除手順を実施してください。
○PostgreSQLのVACUUM FULLコマンドのための容量確保
PostgreSQLのVACUUM FULLコマンドでは、削除対象テーブルのディスク使用量の約2倍のディスク容量が必要となります。そのため、ディスク容量の空きが少ない場合にPostgreSQLのデータを一時的にディスク容量の空きが大きいパスに移動する手順を説明します。
ディスク容量に余裕がある場合は本手順による準備は不要です。各サービスのデータ削除手順を実施してください。
PostgreSQLのデータフォルダが格納されているディスクの容量に空きがない場合、空き容量確保のため一時的に別ディスク(あるいは別パーティション)に退避が可能なフォルダ・ファイルがないかご検討ください。
PostgreSQLのデータフォルダはデフォルトでは以下のパスが該当します。インストール時に個別のパスを指定している場合は読み替えてください。
・Red Hat Enterprise Linux
/var/lib/pgsql/<バージョン番号>/data
・Windows
C:\Program Files\PostgreSQL\<バージョン番号>\data
上記をご確認いただいた上で空き容量を確保することが難しい場合は、PostgreSQLデータフォルダを別の空き容量のある別ディスクに一時的に移動し、VACUUM FULLコマンドを実行してから元のディスクにデータフォルダを戻す手順を実施してください。
事前準備としてPostgreSQLデータフォルダを別ディスクに移動する手順を以下に説明します。
VACUUM FULLコマンドを実行後に元のディスクにデータフォルダを戻す手順は「事後処理」をご参照ください。
【Windows環境の場合】
1. SysMgrGサービス、およびPostgreSQLサービスを停止してください。
2. PostgreSQLのデータフォルダを移動します。
PostgreSQLデータディレクトリ(例:C:\Program Files\PostgreSQL\11\data)を容量が十分あるディスクに移動します。
[注意事項]
・あらかじめ移動前のデータディレクトリのアクセス権をメモしておいてください。
※エクスプローラで該当ディレクトリを選択し、右クリック→プロパティの「セキュリティ」タブの「詳細設定」より確認可能です。
画面キャプチャ等で現在の設定内容を残しておいてください。
・「コピー」ではなく「移動」としてください。
別トライブへの移動の場合、エクスプローラのドラッグ&ドロップではコピーとなります。
そのため、エクスプローラの「ホーム」タブの「移動先」ボタンなどからフォルダ移動してください。
(例)移動元:"C:\Program Files\PostgreSQL\11\data"
→ 移動先:"E:\PostgreSQL_temp"配下
・別ドライブに移動後は、あらかじめメモしておいたアクセス権を手動で再設定してください。
このとき、本作業を実施するユーザのアクセス権がない場合は、フルコントロールで許可するアクセス権を追加してください。
3. 移動後のデータフォルダをPostgreSQLサービスに認識させるためレジストリの変更を行います。
サービスを起動する際に指定するデータディレクトリの値を変更してください。
3-1. レジストリエディタ(regedit)を開き、以下のレジストリキーを確認してください。
・\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\postgresql-x64.<バージョン番号>\ImagePath
・\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\postgresql-x64.<バージョン番号>\ImagePath
・\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\postgresql-x64.<バージョン番号>\ImagePath
3-2. ImagePathに設定されている"-D"オプションの値を変更後のディレクトリに変更してください。
なおVACUUM FULL完了後、元のデータフォルダに戻す場合は、以下の変更を元に戻す必要がありますので必要に応じて変更前の値を控えておいてください。
(例)
変更前:"C:\Program Files\PostgreSQL\11\bin\pg_ctl.exe" runservice -N "postgresql-x64-11" -D "C:\Program Files\PostgreSQL\11\data" -w
変更後:"C:\Program Files\PostgreSQL\11\bin\pg_ctl.exe" runservice -N "postgresql-x64-11" -D "E:\PostgreSQL_temp" -w
4. PostgreSQLサービス→SysMgrGサービスの順でサービスを起動してください。
【Linux環境の場合】
1. SysMgrGサービス、およびPostgreSQLサービスを停止してください。
2. PostgreSQLのデータフォルダを移動します。
PostgreSQLデータディレクトリ(例:/var/lib/pgsql/data)を容量が十分あるディレクトリ(例:/pgsql/data)に移動します。
[注意事項]
・「コピー」ではなく「移動」としてください。
3. 移動後のデータフォルダをPostgreSQLサービスに認識させるため、サービスユニットファイルを修正します。
systemdにて起動を行う際に読み込むサービスユニットファイル(/etc/systemd/system/postgresql.service)のExecStartに設定されている"-D"オプションの値を変更後のディレクトリに変更してください。
なおVACUUM FULL完了後、元のデータフォルダに戻す場合は、以下の変更を元に戻す必要がありますので必要に応じて変更前の値を控えておいてください。
(例)
変更前:ExecStart=/usr/local/pgsql/bin/postgres -D /var/lib/pgsql/data
変更後:ExecStart=/usr/local/pgsql/bin/postgres -D /pgsql/data
4. サービスユニットファイルの変更内容を反映します。
以下のコマンドを実行してください。
systemctl daemon-reload
5. PostgreSQLサービス、SysMgrGサービスの順でサービスを起動してください。
■メッセージストアサービスのデータ削除手順
1. メッセージストアサービス(msc_messagestore)を停止します。
2. メッセージストアのプロパティファイルを編集し、以下のパラメータを設定します。
定期削除時刻は手順3. のサービス起動以降の時刻を設定してください。
詳細はリファレンスガイド「C.1.8 メッセージストア設定ファイル(msc_messagestore.properties)」をご参照ください。
蓄積件数の設定値はリリースメモ「2.2.1.1 ハードウェア要件」をご参照いただき見積もりをお願いします。
【対象ファイル】
<マネージャインストールパス>/conf/msc_messagestore.properties
【設定項目】
・message.delete_schedule
・message.stored_number
3. メッセージストアサービス(msc_messagestore)を起動します。
4. 定期削除時刻で指定した時刻が経過ししばらくしてからメッセージサービスを停止します。
なお、削除処理には時間が掛かります。削除対象のメッセージの件数にもよりますが、半日から1日など十分な時間を待ってから次手順の停止を行ってください。
本手順による削除処理が完了するまで間は、通常の運用を行っていただいて構いません。
ただし、削除処理が動作することによりマシン負荷が高くなったり、画面操作等の応答性能が一時的に低下したりする可能性がありますのでご了承ください。
5. メッセージストアサービス(msc_messagestore)を停止します。
6. メッセージストアサービスのデータベースに接続し、VACUUM FULLコマンドを実行します。
6-1. 以下のコマンドを実行しデータベースに接続します。
パスワードのデフォルトはmsc_messagestoreです。
psql -p 5432 -U msc_messagestore
6-2. メッセージ履歴テーブル名を確認します。以下のコマンドを実行し、「message_<文字列>」となっているテーブルの名前を確認してください。
「message_7f8306fa174c11ec8fca005056b1ad0f」のような名称のテーブルとなります。
なお、SystemMangaer G 10.1以前のバージョンをご利用の場合は本手順は不要です。
\d
6-3. VACUUM FULLを6-2で確認したテーブルに対して実行します。
以下にテーブル名が「message_7f8306fa174c11ec8fca005056b1ad0f」である場合の例を記載します
なお、SystemMangaer G 10.1以前のバージョンをご利用の場合はテーブルに「message」を指定して下さい。
・SystemManager G 11.0以降の場合
VACUUM FULL message_7f8306fa174c11ec8fca005056b1ad0f;
・SystemManager G 10.1以前の場合
VACUUM FULL message;
6-4. 以下のコマンド実行してpostgresから切断してください。
\q
7. 必要に応じて、手順2. で編集したメッセージストアのプロパティファイルの内容を再設定します。
お客様の運用状況に合わせて適宜見直しを実施ください。
設定を変更されない場合、以後は手順2. で指定した内容で定期削除が動作します。
8. メッセージストアサービス(msc_messagestore)を起動します。
■性能データストアサービスのデータ削除手順
SystemManger G 11.0以降をご利用の場合で、性能データ・統計データ・カウンタ情報の保持期間を変更する場合は以下の手順4まで実施してください(手順5以降は不要です)。
SystemManger G 11.0以降をご利用の場合で、上記の設定変更を行わない場合は本手順は省略してください。
SystemManger G 10.1以前をご利用の場合は以下のすべての手順を実施してください。
1. 性能データストアサービスを停止します。
2. 性能データストアのプロパティファイルを編集し、パラメータを設定します。
定期削除時刻の設定は手順3. のサービス起動以降の時刻を設定してください。
詳細はリファレンスガイド「C.1.13 性能データストア設定ファイル(msc_perfdatastore.properties)」をご参照ください。
蓄積日数の設定値はリリースメモ「2.2.1.1 ハードウェア要件」をご参照いただき見積もりをお願いします。
【対象ファイル】
<マネージャインストールパス>/conf/msc_perfdatastore.properties
【設定項目】
・perf_data.delete_schedule
・perf_data.stored_len
・statistics_data.delete_schedule
・statistics_data.stored_len
・counter_deleter.delete_schedule
3. 性能データストアサービスを起動します。
4. 定期削除時刻で指定した時刻が経過ししばらくしてから性能データストアサービス停止します。
削除処理には時間がかかります。削除対象の性能・統計データの件数にもよりますが、半日から1日など十分な時間を待ってから次手順の停止を行ってください。
本手順による削除処理が完了するまで間は、通常の運用を行っていただいて構いません。
ただし、削除処理が動作することによりマシン負荷が高くなったり、画面操作等の応答性能が一時的に低下したりする可能性がありますのでご了承ください。
5. 性能データストアサービスのデータベースに接続し、VACUUM FULLコマンドを実行します。
5-1. 以下のコマンドを実行しデータベースに接続します。
パスワードのデフォルトはmsc_perfdatastoreです。
psql -p 5432 -U msc_perfdatastore
5-2. 以下のとおりVACUUM FULLを実行します。
VACUUM FULL counter;
VACUUM FULL performance;
VACUUM FULL statistics;
6. 必要に応じて、手順2. で設定した性能データストアのプロパティファイルの内容を再設定します。
お客様の運用状況に合わせて適宜見直しを実施ください。
設定を変更されない場合、以後は手順2. で指定した内容で定期削除が動作します。
7. 性能データストアサービス (msc_perfdatastore)を起動します。
■通報サービスのデータ削除手順
1. 通報サービス(msc_report)を停止します。
2. 通報のプロパティファイルを編集し、以下のパラメータを設定します。
定期削除時刻の設定は手順3. のサービス起動以降の時刻を設定してください。
蓄積件数の設定はリリースメモ「2.2.1.1 ハードウェア要件」をご参照いただき見積もりをお願いします。
【対象ファイル】
<マネージャインストールパス>/conf/msc_report.properties
【設定項目】
・history.delete_schedule
・history.stored_number
3. 通報サービス (msc_report) を起動します。
4. 定期削除時刻で指定した時刻が経過ししばらくしてから通報サービスを停止します。
削除処理には時間がかかります。削除対象の件数にもよりますが、半日から1日など十分な時間を待ってから停止するようお願いします。
本手順による削除処理が完了するまで間は、通常の運用を行っていただいて構いません。
ただし、削除処理が動作することによりマシン負荷が高くなったり、画面操作等の応答性能が一時的に低下したりする可能性がありますのでご了承ください。
5. 通報サービス (msc_report) を停止します。
6. 通報サービスのデータベースに接続し、VACUUM FULLコマンドを実行します。
6-1. 以下のコマンドを実行しデータベースに接続します。
psql -p 5432 -U msc_report
6-2. 以下のとおりVACUUM FULLを実行します。
VACUUM FULL history;
VACUUM FULL historyreport;
VACUUM FULL historyactionreport;
7. 必要に応じて、手順2. で編集した通報サービスのプロパティファイルの内容を再設定します。
お客様の運用状況に合わせて適宜見直しを実施ください。
設定を変更されない場合、以後は手順2. で指定した内容で定期削除が動作します。
8. 通報サービス (msc_report) を起動します。
■監視ステータス管理のデータ削除手順
1. 監視ステータス管理サービス(msc_status)を停止します。
2. 監視ステータス管理のプロパティファイルを編集し、以下のパラメータを設定します。
定期削除時刻の設定は手順3. のサービス起動以降の時刻を設定してください。
蓄積期間の設定はリリースメモ「2.2.1.1 ハードウェア要件」をご参照いただき見積もりをお願いします。
【対象ファイル】
<マネージャインストールパス>/conf/msc_status.properties
【設定項目】
・history.delete_schedule
・history.stored_len
3. 監視ステータス管理サービス (msc_status) を起動します。
4. 定期削除時刻で指定した時刻が経過ししばらくしてから監視ステータス管理サービスを停止します。
削除処理には時間がかかります。削除対象の件数にもよりますが、半日から1日など十分な時間を待ってから停止するようお願いします。
本手順による削除処理が完了するまで間は、通常の運用を行っていただいて構いません。
ただし、削除処理が動作することによりマシン負荷が高くなったり、画面操作等の応答性能が一時的に低下したりする可能性がありますのでご了承ください。
5. 監視ステータス管理サービス (msc_status) を停止します。
6. 監視ステータス管理サービスのデータベースに接続し、VACUUM FULLコマンドを実行します。
6-1. 以下のコマンドを実行しデータベースに接続します。
psql -p 5432 -U msc_status
6-2. 以下のとおりVACUUM FULLを実行します。
VACUUM FULL msc_status_nodeinfo_history;
VACUUM FULL msc_status_statusinfo_history;
VACUUM FULL msc_status_tags;
7. 必要に応じて、手順2. で編集した監視ステータス管理サービスのプロパティファイルの内容を再設定します。
お客様の運用状況に合わせて適宜見直しを実施ください。
上記のデータは稼働状況のグラフ表示(分析/レポート画面)で利用しますが、該当機能をご利用でない場合は保持日数を最小の値に設定してください。画面の詳細は操作ガイド「2.10.4 稼働状況グラフの設定」をご参照ください。
設定を変更されない場合、以後は手順2. で指定した内容で定期削除が動作します。
8. 監視ステータス管理サービス (msc_status) を起動します。
■事後処理
「事前準備」でデータフォルダを移動し元のパスに戻す場合は、以下の手順を実施してください。
移行後のデータフォルダを継続利用される場合は本手順の実施は不要です。
1. SysMgrGサービス、およびPostgreSQLサービスを停止してください。
2. 「事前準備」の手順2. と逆の操作で、移行したデータフォルダから元のデータフォルダに移動させます。
3. 「事前準備」の手順3. で設定したレジストリキーの"-D"オプションを変更前の値に戻します。
4. PostgreSQLサービス、SysMgrGサービスの順でサービスを起動してください。
■ディスク設計の見直し
・SystemManager Gの監視運用でのディスク使用量の概算方法はリリースメモに記載があります。
必要に応じて、本手順の実施とあわせて現行のディスク設計およびSystemManager Gの保持するデータの期間や件数の再設計をご検討ください。