障害発生に備えて設定すべき3つのログ関連パラメーター

今回はPostgreSQLにおいて、障害発生に備えて設定すべき3つのログ関連パラメーターを紹介します。これらのパラメーターを設定しておくことで、障害発生時にその状況を詳細に把握することができます。障害の原因および対策を見つけられる可能性が高くなりますので、ぜひ忘れずに設定しておきましょう。

PostgreSQLのログ出力には、Linuxの場合はsyslog、Windowsの場合はeventlogのログ機能などを選択できますが、今回はPostgreSQL独自のログ機能を使用することを前提として解説します。

障害発生に備えて、アシストサポートセンターが推奨するログ関連パラメーターの設定は以下の3つです。

上記3つのパラメーターをpostgresql.confに設定することで、ログファイルには次のように出力されます。

上記3つのパラメーターを設定しておくことで、調査に必要な情報(タイムスタンプ、接続先ユーザー名、接続先データベース名、プロセスIDなど)がログファイルに記録され、障害発生時の状況を調査しやすくなります。


以降では、各パラメーターの概要、設定方法、ログファイルの出力例についてご紹介していきます。

logging_collectorでは、標準エラー(stderr)またはCSV書式のログ出力に送られるメッセージを取り出し、ログファイルにリダイレクトするか否かをon/offで設定します。PostgreSQLをソースファイルからインストールした場合、デフォルト値はoffに設定されています。つまり、ログファイルは生成されません。

一方、EnterpriseDB社が提供するインストールモジュールやRPMパッケージからインストールした場合には、デフォルト値がonに設定されているため、ログファイルは生成されます。ただし、このパラメーターをonに設定しただけでは、ログファイルから確認できる情報はメッセージのみとなり、エラーが発生した日時、ユーザ名、データベース名がわかりませんので、他の2つのパラメーターも合わせて設定する必要があります。

　
1) PostgreSQLをインストールしたOSユーザーまたはAdministratorユーザーでログイン
　
2) postgresql.confの編集
　PGDATA/postgresql.confを開き、logging_collectorの値がoffの場合はonに変更します。
　
3) PostgreSQLサービスの再起動
　[スタート]→[コントロールパネル]→[管理ツール]→[サービス]からサービス一覧を表示し、PostgreSQLのサービスを再起動します。

　※PGDATAは、データベース格納領域であるデータベースクラスタのパスを設定する環境変数です。

　
1) PostgreSQLをインストールしたOSユーザーに接続
　# su - <PostgreSQLをインストールしたOSユーザー名>
　
2) postgresql.confの編集
　PGDATA/postgresql.confを開き、logging_collectorの値がoffの場合はonに変更します。
　
3) PostgreSQLの再起動
　$ pg_ctl restart

デフォルト設定では、PGDATA/pg_log配下にpostgresql-%Y-%m-%d_%H%M%S.logの書式でログファイルが生成されます。以下の例では、logging_collector=onを設定した状態でtest_ind索引を作成しようとして失敗した際にログファイルに記録された内容を表示しています。ログファイルからERRORメッセージが発生していることは確認できますが、いつどのデータベースで発生したERRORメッセージであるかを確認することはできません。

log_line_prefixでは、各ログ行の先頭に付与するプレフィックスを設定します。デフォルト設定では何も設定されていません。 %から始まるエスケープシーケンス を設定することで、各ステータス情報に置き換えられます。例えば、%tはタイムスタンプ、%uはデータベースのユーザー名、%dはデータベース名、%pはOSのPID、%lは各セッション/プロセス毎のログ行番号に置き換えられます。

　
1) PostgreSQLをインストールしたOSユーザーまたはAdministratorユーザーでログイン
　
2) postgresql.confの編集
　PGDATA/postgresql.confを開き、log_line_prefixの値を'[%t]%u %d %p[%l]'に設定します。
　
3) PostgreSQLのリロード
　 DOS> pg_ctl reload

　
1) PostgreSQLをインストールしたOSユーザーに接続
　# su - <PostgreSQLをインストールしたOSユーザー名>

2) postgresql.confの編集
　PGDATA/postgresql.confを開き、log_line_prefixの値を'[%t]%u %d %p[%l]'に設定します。

3) PostgreSQLのリロード
　$ pg_ctl reload

以下の例は、log_line_prefix='[%t]%u %d %p[%l]'を設定した状態でtest_ind索引を作成しようとして失敗した際にログファイルに記録された内容を表示しています。logging_collector=onだけを設定していた時とは異なり、いつどこでERRORメッセージが発生しているかを確認できるようになっています。これらの情報から、今回のERRORメッセージはtestuserユーザーでpostgresデータベース内に存在しないtest表に対して索引を作成しようとしたために発生したことがわかります。

log_min_duration_statementでは、SQLの実行に指定したミリ秒以上の時間がかかった場合に、そのSQLと所要時間をログファイルに記録します。デフォルト値は、-1（SQLおよびその所要時間の記録をしない）に設定されています。このパラメーターに許容できないレスポンス時間を設定することで、ログファイルからスロークエリを把握することができます。

　
1) PostgreSQLをインストールしたOSユーザーまたはAdministratorユーザーでログイン
　
2) postgresql.confの編集
　PGDATA/postgresql.confを開き、log_min_duration_statementの値に許容できないレスポンス時間(ミリ秒)を設定します。

3) PostgreSQLのリロード
　　DOS> pg_ctl reload

　
1) PostgreSQLをインストールしたOSユーザーに接続
　# su - <PostgreSQLをインストールしたOSユーザー名>

2) postgresql.confの編集
　PGDATA/postgresql.confを開き、log_min_duration_statementの値に許容できないレスポンス時間(ミリ秒)を設定します。

3) PostgreSQLのリロード
　$ pg_ctl reload

以下の例は、log_min_duration_statement=10000を設定した状態で10秒以上かかるSQLを実行した際にログファイルに記録された内容を表示しています。 ログファイルからスロークエリを確認できたら、スロークエリで参照するテーブルの統計情報が最新であるかやEXPLAIN ANALYZE <スロークエリ>コマンドを使用して適切な実行計画で処理が行われているかなど、ボトルネックがどこにあるかを確認することで改善策を検討できます。

今回は、障害発生に備えて設定すべきパラメーターとして、logging_collector、log_line_prefix、log_min_duration_statementの3つをご紹介しました。これらを設定いただくことで、障害発生時の状況把握、問題解決がスムーズになりますので、ぜひこれを機に設定の有無を確認してみてください。

なお、今回紹介したパラメーター以外にもPostgreSQLの状況把握に役立つログ関連パラメーターは複数存在しますので、興味のある方は マニュアル もあわせてご参照ください。