【PostgreSQL】最低限設定しておくべきログ関連パラメータ3選:データベースサポート最前線の現場から(8)(1/3 ページ)
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、PostgreSQLの障害発生に備えて設定しておくべき「3つのログ関連パラメータ」を紹介します。
今回は、PostgreSQLの障害発生に備えて設定しておくべき3つのログ関連パラメータを紹介します。これらのパラメータを設定しておくことで、障害発生時にその状況を詳細に把握できます。逆に、設定しておかないと障害の原因や対策が困難になります。ぜひ忘れずに設定しておきましょう。
PostgreSQLのログ出力には、Linux系システムならばsyslog、Windows系システムならばeventlogのログ機能なども選択できますが、今回はPostgreSQL独自のログ機能を活用してみましょう。
3つのログ関連パラメータを設定しておく
設定しておくべきログ関連パラメータの設定は以下の3つです。
- 1:logging_collector=on
- 2:log_line_prefix='[%t]%u %d %p[%l]'
- 3: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;
ログファイルには、調査に必要な情報である「タイムスタンプ」「接続先ユーザー名」「接続先データベース名」「プロセスID」など出力されているのが分かるでしょうか。この情報が障害発生時の状況を調べるのに最低限必要な情報です。
具体的にどのように設定していくか、順に解説していきます。
1:logging_collector
「logging_collector」では、標準エラー(stderr)、またはCSV書式のログ出力に送られるメッセージを取り出し、ログファイルにリダイレクトするかどうかを「on」か「off」で指定します。PostgreSQLをソースファイルからインストールした場合の初期値は「off」に設定されています。つまり、ログファイルは生成されません。
一方、PostgreSQLをエンジンとするEnterpriseDBの「EDB Postgres」のインストールモジュールやRPMパッケージからインストールした環境の初期値は「on」に設定されています。ただし、このパラメータだけでは必要な情報が足りません。ログファイルから確認できる情報はメッセージだけで、エラーが発生した日時やユーザー名、データベース名などが分かりません。このため、後述する2つのパラメータも併せて設定する必要があります。
設定方法(Linux系システムの場合)
- 1:PostgreSQLをインストールしたOSユーザーに接続
# su - <PostgreSQLをインストールしたOSユーザー名>
- 2:「PGDATA/postgresql.conf」を開き、logging_collectorの値がoffだった場合は、「on」に修正する
- 3:PostgreSQLを再起動する
$ pg_ctl restart
設定方法(Windows系システムの場合)
- 1:PostgreSQLをインストールしたOSユーザー、あるいはAdministratorユーザーでログインする
- 2:「PGDATA(*)/postgresql.conf」を開き、logging_collectorの値がoffだった場合は、「on」に修正する
- 3:「管理ツール」→「サービス」→「PostgreSQL」から、PostgreSQLを再起動する
ログファイルの出力例
初期設定では、PGDATA/pg_log/以下に「postgresql-%Y-%m-%d_%H%M%S.log」のファイル名でログファイルが生成されます。
「test_ind索引を作成しようとして失敗した」際に生成されたログファイルの内容は以下の通りです(例1)。
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);
例1では、4行目で「relation "test" does not exist」というエラーが発生したことを確認できます。しかし、このエラーが、いつ、どのデータベースで発生したのかまでは分かりません。トラブル調査を行うには、もっと詳細な情報が必要です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 「新機能」「廃止機能」「サポート状況」から見たユーザーにとってのOracle Database 12c
Oracle Database導入を実施ならびに支援するサービスプロバイダという筆者の立場から、ユーザーにとっての新バージョンの意義を考えながら、新機能や廃止された機能などを紹介します。 - オラクルが確約した「クラウド6箇条」と「Database 12c R2」の気になるトコロ
米オラクルのラリー・エリソンCTOが、同社の年次イベントで今後のクラウド事業の行方を確約する「Oracle Cloud、6つの設計目標」を掲げました。同時に発表された基幹製品「Oracle Database 12c」の次期バージョンのポイントと共に、そこにどんな狙いがあるかを振り返ります。 - オラクルのエリソン会長、「Oracle Database」最新版や多数のクラウドイノベーションを発表
米オラクルのラリー・エリソン氏は「Oracle OpenWorld 2016」の開幕基調講演を行い、同社のクラウドコンピューティングプラットフォーム全般にわたる多くのイノベーションを披露した。 - 【Oracle Database】忘れていませんか? 「アラートログ調査」に必要な、たった3つのキホン
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は基本編として「アラートログの調査で押さえるべき3つのポイント」を解説します。【Oracle Database 12c対応版】 - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。 - カーソル・エラーとオブジェクトの問題切り分け
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) - IF文のネスト地獄から抜け出せるMERGE文