Database Support Blog

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

  • PostgreSQL
2015.11.17

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

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

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

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

3つのログ関連パラメーター

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

  • logging_collector=on
  • log_line_prefix='[%t]%u %d %p[%l]'
  • log_min_duration_statement=<許容できないレスポンス時間(ミリ秒)>


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

[2015-08-30 20:40:26 JST]testuser postgres 3414[1]ERROR: relation "test" does not exist
[2015-08-30 20:40:26 JST]testuser postgres 3414[2]STATEMENT: create index test_ind on test(no);
[2015-08-30 21:28:20 JST] 2727[6]LOG: parameter "log_min_duration_statement" changed to "10000"
[2015-08-30 21:29:26 JST]testuser postgres 17060[1]LOG: duration: 63122.171 ms statement: select * from pgbench_accounts where aid>5000;


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


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

1. logging_collector

概要

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

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

設定方法

Windowsの場合

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

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

Linuxの場合

 
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: database system was shut down at 2015-08-30 20:23:22 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
ERROR: relation "test" does not exist
STATEMENT: create index test_ind on test(no);


2. log_line_prefix

概要

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

設定方法

Windowsの場合

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

Linuxの場合

 
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: received SIGHUP, reloading configuration files
[2015-08-30 20:36:22 JST] 2727[5]LOG: parameter "log_line_prefix" changed to "[%t]%u %d %p[%l]"
[2015-08-30 20:40:26 JST]testuser postgres 3414[1]ERROR: relation "test" does not exist
[2015-08-30 20:40:26 JST]testuser postgres 3414[2]STATEMENT: create index test_ind on test(no);

<上記ログ出力から確認できる当該ERRORメッセージに関する情報>
----------------------------------------------------------------------------------------------------
発生時刻:2015-08-30 20:40:26
処理を実行したユーザー名:testuser
接続先データベース名:postgres
OSのPID:3414
PID 3414に関連するメッセージ1:ERROR: relation "test" does not exist
PID 3414に関連するメッセージ2:STATEMENT: create index test_ind on test(no);
----------------------------------------------------------------------------------------------------


3. log_min_duration_statement

概要

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

設定方法

Windowsの場合

 
1) PostgreSQLをインストールしたOSユーザーまたはAdministratorユーザーでログイン

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

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

Linuxの場合

 
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 <スロークエリ>コマンドを使用して適切な実行計画で処理が行われているかなど、ボトルネックがどこにあるかを確認することで改善策を検討できます。

[2015-08-30 21:28:20 JST] 2727[6]LOG: parameter "log_min_duration_statement" changed to "10000"
[2015-08-30 21:29:26 JST]testuser postgres 17060[1]LOG: duration: 63122.171 ms statement: select * from pgbench_accounts where aid>5000;

<上記ログ出力から確認できるスロークエリに関する情報>
----------------------------------------------------------------------------------------------------
検出時刻:2015-08-30 21:29:26
処理を実行したユーザー名:testuser
接続先データベース名:postgres
OSのPID:17060
PID 17060に関連するメッセージ1:LOG: duration: 63122.171 ms statement: select * from pgbench_accounts where aid>5000;
スロークエリ:select * from pgbench_accounts where aid>5000;
所要時間:63122.171 ms (約63秒)
----------------------------------------------------------------------------------------------------


まとめ

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

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


執筆者情報

家島 拓也

2007年にアシストに入社して以来、ORACLE製品やPostgreSQL・EDB Postgres製品のサポートに従事してきました。このブログではサポート対応で得た知識を元に、お客様がお困りになることが多い問題や各製品の新機能に関する検証結果などを提供します。

関連している記事

  • PostgreSQL
2016.12.01

【SR+HS環境の落とし穴】スタンバイが要求したWALが上書きされる障害の予防策

PostgreSQLのSR+HS環境でスタンバイが要求したWALが上書きされる障害の予防策を紹介します。

  • EDB Postgres
  • PostgreSQL
2016.11.11

【EDB Postgres/PostgreSQL】うるう秒(閏秒)の対応

EDB Postgres/PostgreSQLでのうるう秒(閏秒)の対応方法について解説します。2017年元旦にトラブルとならないよう、準備しましょう。

  • PostgreSQL
2016.10.04

性能劣化を引き起こすチェックポイント多発の確認・対処方法

チェックポイントはディスクI/Oを伴うため、短い間隔で繰り返し実行されると性能劣化の原因となります。PostgreSQL(9.5以降)でチェックポイント多発の確認と、多発していた場合の対処方法について説明します。

アシストサポートセンターのご紹介 Oracle Database研修

ページの先頭へ戻る