はじめに
Procss Server(process engine)は、リポジトリDBとしてPostgreSQLを利用しています。Process ServerにはリポジトリDBが不可欠であり、このDBが起動しない状態になるとProcess Serverも起動できない状態となるため、PostgreSQLの管理に関する知識は重要です。
この記事では、Procss ServerがリポジトリDBとして利用するPostgreSQLの管理、トラブルシューティングについてまとめてみました。
リポジトリDBの用途
リポジトリDBとして利用されるPostgreSQLでは次のような情報が管理されています。
- Process Serverにデプロイされたアセットの情報
- 実行されたアセットのログ情報
- Process Serverの設定情報
たとえば、PostgreSQLが起動できない状態となりDBの初期化を実行すると上記の情報が失われるため、バックアップデータのリストアが必要になります。もし、バックアップから正常にリストアできない場合には、アセットの再デプロイが必要になる点に注意します。
ストレージ管理
PostgreSQLのデータ領域が肥大化する要因の一つに、アセットのログ情報があげられます。Process ServerのPostgreSQLはアセットのログ情報が肥大化しないように自動的にメンテナンスされるように構成されています。
自動メンテナンスの設定を確認するには、アプリケーション統合コンソールの サーバーの環境設定 > ストレージ のページから確認できます。
初期設定では、正常に終了したプロセスの情報は1日で、異常終了(フォールト)したプロセスの情報は3日でクリーンアップされます。
プロセスの情報がクリーンアップされると、アプリケーション統合コンソールのページから終了したプロセスの情報を参照できない状態となります。そのため、開発環境では、どちらも少し期間を延ばして保存しておくのもよいでしょう。また、本番環境では、エラー発生後にトラブルシューティングを行えるように、異常終了したプロセスのクリーンアップ期間を初期設定のままにするか、7日程度に延ばか、をプロジェクトにて検討すると良いと思います。
不要ファイルのメンテナンス
以下のディレクトリに生成されるファイルについて手動メンテナンスが必要です。
- /apps/process-engine/logs
- /apps/process-engine/logs/engine
- /apps/process-engine/logs/PostGreSql
- /apps/process-engine/data/backup/linux64(もしくはwin64)
logs および logs/engine
これらのディレクトリに生成されているファイルのうち *.YYYY-MM-DD.log という形式のファイル、*-X.log(Xは数字) という形式のファイルは直近3つ分を残してクリーンアップできます。
なぜ 直近3つ分 のログファイルを残すのか？
概ね直近3つ分のログがあれば問題ないだろうという想定の下の指針です。例えば、問題が発生した時に可能な限りの調査をする必要がある場合には、ログファイルを削除せずにZip圧縮するなどして保管します。
注意が必要なファイルは拡張子が hprof のファイルです。このファイルはProcess Serverにおいて何らかの問題が発生した際に出力されるJavaのヒープダンプです。ヒープダンプはファイルサイズが大きくなりやすいため、出力されている場合には削除またはZip圧縮して保管します。Zip圧縮すると10分の1程度になるようです。
$ zip java_pid640482.hprof.zip java_pid640482.hprof
adding: java_pid640482.hprof (deflated 92%)
logs/PostGreSql
このディレクトリに出力されているログファイルをクリーンアップする場合には事前に、Secure Agentを停止して、更にPostgreSQLを手動停止します。PostgreSQLを手動停止するにはコマンド /apps/process-engine/data/db/util/server_stop.sh を実行します(Windowsの場合はserver_stop.bat)。
停止コマンド実行後、コマンド /apps/process-engine/data/db/util/server_status.sh を実行して server stopped が出力されていればPostgreSQLが停止していることを意味します(Windowsの場合はserver_status.bat)。
data/backup/linux64(もしくはwin64)
このディレクトリにはPostgreSQLを起動できない場合や、稼働に問題がある場合に利用できるバックアップファイル(拡張子 dump)が保存されています。バックアップファイルはサイズが大きくなりやすく、Secure Agentの再起動毎に取得されるため注意が必要です。
基本的な方針としては直近5ファイル分、または過去2ヵ月に出力されているファイルのうち少ない方を目安に保管します。
参考までの情報となりますが私が動作確認で利用している環境では、1年で合計4GB弱のバックアップファイルが作成されておりました(デプロイしているアセット数が多い場合、実行量が多い場合、サイズはこれよりも大きくなると想定されます)。
起動時のトラブルシューティング
PostgreSQLが起動しない場合は次のポイントを確認します。
- 初期インストール後から起動しない
- Linux環境の場合、Secure Agentを非rootユーザーで起動しており、かつ、Secure Agentの起動を非rootユーザーで実行している点を確認します。
- Windows環境の場合、必要な権限がSecure Agentの起動ユーザーに割り当てられていることをKB ERROR: "Postgre Server failed to start - waiting for server to start....The current directory is invalid" in Cloud Application Integrationに従って確認します。
もしKBに記載の権限が割り当てられているにも関わらずPostgreSQLが起動しない場合、かつ、ドメインユーザーを利用してSecure Agentを起動している場合には、ローカルユーザーを利用して動作確認します。
- XX日前まで起動していたのに突如起動しなくなった
- 起動ユーザーの変更、ディレクトリの権限設定の変更が行われている経緯があるかを確認します。特にLinux環境では誤ってrootユーザーを利用してSecure Agentを起動すると、PostgreSQL用のログファイル・ロックファイルがrootユーザー権限で作成され、以降、非rootユーザーによる起動に失敗する状況が発生しえます。