sql >> データベース >  >> RDS >> PostgreSQL

PostgreSQLエラーログをデコードする方法

    PostgreSQLのエラー報告は、データベース管理者に問題の効率的なトラブルシューティングに必要な情報を提供することを目的としたスタイルガイドに従います。エラーメッセージには通常、簡単な説明、詳細情報、および該当する場合は解決策を提案するヒントが含まれています。エラーが一時的であるか永続的であるかを示すための過去形または現在形の使用など、ガイドで説明されている他の詳細があります。

    エラーの種類と重大度

    エラーを報告する場合、PostgreSQLはSQLSTATEエラーコードも返すため、エラーはいくつかのクラスに分類されます。クラスのリストを確認するときは、成功と警告もPostgreSQLによってエラーログに記録されることに注意してください。これは、ロギングを担当するPostgreSQLプロセスであるlogging_collectorがすべてのメッセージを stderrに送信するためです。 デフォルトで。

    ロギングコレクターが初期化されていない場合、エラーはシステムログに記録されます。たとえば、パッケージのインストール後にサービスを開始しようとすると、次のようになります。

    [[email protected] ~]# systemctl start postgresql
Job for postgresql.service failed because the control process exited with error code.
See "systemctl  status postgresql.service" and "journalctl  -xe" for details.
[[email protected] ~]# systemctl status postgresql
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-01-24 19:10:04 PST; 8s ago
Process: 1945 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=1/FAILURE)

Jan 24 19:10:04 omiday.can.local systemd[1]: Starting PostgreSQL database server...
Jan 24 19:10:04 omiday.can.local postgresql-check-db-dir[1945]: Directory "/var/lib/pgsql/data" is missing or empty.
Jan 24 19:10:04 omiday.can.local postgresql-check-db-dir[1945]: Use "/usr/bin/postgresql-setup --initdb"
Jan 24 19:10:04 omiday.can.local postgresql-check-db-dir[1945]: to initialize the database cluster.
Jan 24 19:10:04 omiday.can.local postgresql-check-db-dir[1945]: See /usr/share/doc/postgresql/README.rpm-dist for more information.
Jan 24 19:10:04 omiday.can.local systemd[1]: postgresql.service: Control process exited, code=exited status=1
Jan 24 19:10:04 omiday.can.local systemd[1]: Failed to start PostgreSQL database server.
Jan 24 19:10:04 omiday.can.local systemd[1]: postgresql.service: Unit entered failed state.
Jan 24 19:10:04 omiday.can.local systemd[1]: postgresql.service: Failed with result 'exit-code'.

    エラーメッセージをクライアントに返す場合、つまりエラーログに記録する場合、メッセージはclient_min_messagesパラメータを使用して制御される重大度レベルでログに記録されます。サーバーログファイルへのログ記録は、パラメータlog_min_messagesによって制御されますが、log_min_error_statementは、特定の重大度レベルのエラーを引き起こすSQLステートメントのログ記録を有効にします。

    PostgreSQLは、次の重大度レベルでログに記録するように構成できます。

    • パニック： すべてのデータベースセッションが中止されます。これは、すべてのクライアントに影響を与える重大な状況です。
    • 致命的： エラーのため、現在のセッションは中止されます。クライアントは再試行できます。クラスタ内の他のデータベースは影響を受けません。
    • ログ： 通常の操作メッセージ。
    • エラー： コマンドの実行に失敗しました。これは永続的なエラーです。
    • 警告： コマンドの完了を妨げることはありませんが、対処しないと失敗につながる可能性のあるイベント。警告を監視することは、サーバー側とアプリケーション側の両方で問題を早期に検出するための良い方法です。
    • 注意： クライアントがコードを改善するために使用できる情報。
    • 情報： クライアントから明示的に要求されたログ。
    • DEBUG1..DEBUG5： 開発者情報。

    注：上位レベルのメッセージには、下位レベルからのメッセージが含まれます。つまり、ログレベルをLOGに設定すると、PostgreSQLにFATALメッセージとPANICメッセージもログに記録するように指示されます。

    一般的なエラーとその修正方法

    以下は網羅的ではないリストです：

    エラーメッセージ

    psql: could not connect to server: No such file or directory

    原因

    [[email protected] ~]# psql -U postgres
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

    解決策

    オペレーティングシステムツール（ps、netstat、ss、systemctl）を使用してPostgreSQLサービスが実行されていることを確認するか、データディレクトリにpostmaster.pidが存在するかどうかを確認します。

    エラーメッセージ

    psql: FATAL:  Peer authentication failed for user "postgres"

    原因

    [[email protected] ~]# psql -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"

    解決策

    ログファイルには、その旨のより詳細なメッセージが含まれます：

    LOG:  provided user name (postgres) and authenticated user name (root) do not match
FATAL:  Peer authentication failed for user "postgres"
DETAIL:  Connection  matched  pg_hba.conf  line  80:  "local  all  all  peer"

    次の手順に従ってください：

    1. postgresユーザーとしてログインします：

      [[email protected] ~]# su - postgres
[[email protected] ~]$ psql
psql (9.6.6)
Type "help" for help.

postgres=#

    2. rootユーザーがパスワードなしでログインできるようにpg_hba.confに次の変更を加えます。

      --- a/var/lib/pgsql/data/pg_hba.conf
+++ b/var/lib/pgsql/data/pg_hba.conf
@@ -77,6 +77,7 @@
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
+local   all             postgres                                trust
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident

    3. サービスをリロードしてテストします：

      [[email protected] ~]# psql -U postgres
psql (9.6.6)
Type "help" for help.

postgres=#

    エラーメッセージ

    psql: could not connect to server: Connection refused
        Is the server running on host "192.168.0.11" and accepting
        TCP/IP connections on port 5432?

    原因

    クライアントがパブリックIPアドレスへの接続を試みました。

    注：これは、上記のpsqlの例では、クライアントに返されるエラーです。 Webアプリケーションの場合は、Webサーバーのエラーログを確認してください。

    解決策

    パブリックIPアドレスでリッスンするようにサービスを構成します：

    注：ベストプラクティスとして、postgresql.confを編集するのではなく、altersystemを使用してください。 

    postgres=# alter system set listen_addresses TO 'localhost,192.168.0.11';
ALTER SYSTEM

    alter systemコマンドは、以下に示すようにpostgresql.auto.confを変更しました：

    --- a/var/lib/pgsql/data/postgresql.auto.conf
+++ b/var/lib/pgsql/data/postgresql.auto.conf
@@ -1,2 +1,3 @@
# Do not edit this file manually!
-# It will be overwritten by the ALTER SYSTEM command.
+# It will be overwritten by ALTER SYSTEM command.
+listen_addresses = 'localhost,192.168.0.11'

    サービスを再起動してテストします：

    [[email protected] ~]# psql -U webuser -h 192.168.0.11 webapp
psql: FATAL:  no pg_hba.conf entry for host "192.168.0.11", user "webuser", database "webapp", SSL off

    このエラーについては、次のトピックで対処します。

    エラーメッセージ

    psql: FATAL:  no pg_hba.conf entry for host "192.168.0.11", user "webuser", database "webapp", SSL off

    原因

    IPアドレス192.168.0.11で実行されているPostgreSQLサービスは、ユーザーwebuserがデータベースwebappに接続できるように構成されていません。

    解決策

    アクセスファイルpg_hba.confを変更して、接続を許可します。

    --- a/var/lib/pgsql/data/pg_hba.conf
+++ b/var/lib/pgsql/data/pg_hba.conf
@@ -81,6 +81,7 @@
local   all             postgres                                trust
local   all             all                                     peer
# IPv4 local connections:
host    all             webuser         127.0.0.1/32            md5
+host    all             webuser         192.168.0.11/32         md5
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             webuser         ::1/128                 md5

    サービスをリロードしてテストします：

    [[email protected] ~]# psql -U webuser -h 192.168.0.11 webapp
Password for user webuser:
psql (9.6.6)
Type "help" for help.

webapp=> \c
You are now connected to database "webapp" as user "webuser".

    エラーメッセージ

    ERROR:  syntax error at or near "grant"

    原因

    GrantはPostgreSQLの予約キーワードの1つです

    解決策

    予約キーワードは引用符で囲む必要があります：

    webapp=> create table "grant" (id numeric);
CREATE TABLE
And verify:
webapp=> \d "grant"
     Table "public.grant"
 Column |  Type   | Modifiers
--------+---------+-----------
 id     | numeric |

webapp=>

    エラーメッセージ

    ERROR:  cannot drop table cust because other objects depend on it

    原因

    クライアントが子テーブルを持つテーブルカストを削除しようとしました。

    解決策

    ログファイルのHINTを確認します：

    ERROR:  cannot drop table cust because other objects depend on it
DETAIL:  table cust_region_1 depends on table cust
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT:  drop table cust;

    エラーメッセージ

    ERROR:  invalid input syntax for type numeric: "b" at character 26

    原因

    ログファイルは、列タイプと一致しない値を挿入しようとしたことを示しています：

    ERROR:  invalid input syntax for type numeric: "b" at character 26
STATEMENT:  insert into cust values ('b', 2);

    解決策

    これはアプリケーション側のエラーであり、開発者が修正する必要があるか、psqlを実行しているDBAなどのクライアントによって開始された場合に修正する必要があります。完全なエラーメッセージもクライアントに返されたため、本番DBAはアクションを実行する必要はありません。

    今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

    ログの確認と監視

    最も簡単なオプションは、log_destinationパラメーターを介してsyslogを使用するようにPostgreSQLを構成することです。これにより、ログをお気に入りの集中ログシステム（rsyslogなど）に送信し、そこでさらに処理して特定のエラー状態を警告できます。

    ほぼゼロのセットアップを必要とする別のツールは、cronデーモンと組み合わせて機能するtail_n_mailです。

    このリストのさらに別のツールはpgBadgerで、PostgreSQLログファイルだけでなく、統計コレクターによってログに記録された情報もレポート、視覚化、分析するための豊富なオプションセットが付属しています。

    複雑さのスケールを上げると、組織は、FilebeatPostgreSQLモジュールを使用してアラートとレポートを生成するELKスタックをセットアップするための時間と労力を投資することで利益を得ることができます。

    結論

    エラーログを確認し、重大な問題について通知を受け、トラブルシューティングに役立つ多用途のログ管理システムを用意することは、健全なデータベース環境を維持するために重要です。幸い、PostgreSQLは豊富なエラー管理フレームワークを提供し、選択可能な多種多様な製品に反映されています。特定の環境に最適なものを選択するための基準には、製品の機能だけでなく、必要な技術的専門知識も含まれている必要があります。


    1. LogMinerを使用して現在の変更を見つける

    2. PL/SQLを学習するための開発環境のセットアップ

    3. OracleのCURRENT_TIMESTAMP（）関数

    4. postgresでのcreatedbの問題