PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Come decodificare i log degli errori di PostgreSQL

La segnalazione degli errori PostgreSQL segue una guida di stile volta a fornire all'amministratore del database le informazioni necessarie per risolvere i problemi in modo efficiente. I messaggi di errore normalmente contengono una breve descrizione, seguita da alcune informazioni dettagliate e un suggerimento, se applicabile, che suggerisce la soluzione. Ci sono altri dettagli fini, spiegati nella guida, come l'uso del passato o del presente per indicare se l'errore è temporaneo o permanente.

Tipi di errore e livelli di gravità

Quando si segnalano gli errori, PostgreSQL restituirà anche un codice di errore SQLSTATE, quindi gli errori sono classificati in diverse classi. Quando si esamina l'elenco delle classi, si noti che il successo e l'avviso vengono registrati anche da PostgreSQL nel registro degli errori, poiché logging_collector, il processo PostgreSQL responsabile della registrazione, invia tutti i messaggi a stderr per impostazione predefinita.

Quando il raccoglitore di registrazione non è stato inizializzato, gli errori vengono registrati nel registro di sistema. Ad esempio, quando si tenta di avviare il servizio dopo l'installazione del pacchetto:

[[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'.

Quando si restituiscono messaggi di errore ai client, e quindi si registrano nel registro errori, i messaggi vengono registrati con un livello di gravità controllato tramite il parametro client_min_messages. La registrazione nei file di registro del server è controllata dal parametro log_min_messages, mentre log_min_error_statement abilita la registrazione delle istruzioni SQL che causano un errore di un livello di gravità specifico.

PostgreSQL può essere configurato per accedere ai seguenti livelli di gravità:

  • PANICO: Tutte le sessioni del database vengono interrotte. Questa è una situazione critica che riguarda tutti i clienti.
  • FATALE: La sessione corrente viene interrotta a causa di un errore. Il cliente può riprovare. Gli altri database nel cluster non sono interessati.
  • LOGO: Messaggi di normale funzionamento.
  • ERRORE: Mancata esecuzione di un comando. Questo è un errore permanente.
  • ATTENZIONE: Un evento che, pur non impedendo il completamento del comando, può portare a errori se non affrontato. Il monitoraggio degli avvisi è una buona pratica per il rilevamento precoce di problemi sia lato server che lato applicazione.
  • AVVISO: Informazioni che i clienti possono utilizzare per migliorare il proprio codice.
  • INFO: Registri esplicitamente richiesti dai client.
  • DEBUG1..DEBUG5: Informazioni sullo sviluppatore.

Nota:i messaggi di livello superiore includono i messaggi dei livelli inferiori, ad es. l'impostazione del livello di registrazione su LOG, indicherà a PostgreSQL di registrare anche i messaggi FATAL e PANIC.

Errori comuni e come risolverli

Quello che segue è un elenco non esaustivo:

Messaggio di errore

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

Causa

[[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"?

Risoluzione

Verifica che il servizio PostgreSQL sia in esecuzione utilizzando gli strumenti del sistema operativo (ps, netstat, ss, systemctl) o verifica la presenza di postmaster.pid nella directory dei dati.

Messaggio di errore

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

Causa

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

Risoluzione

Il file di registro conterrà un messaggio più dettagliato in tal senso:

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"

Segui questi passaggi:

  1. Accedi come utente postgres:

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

postgres=#

  2. Apporta la seguente modifica a pg_hba.conf che consentirà all'utente root di accedere senza password:

    --- 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. Ricarica il servizio e prova:

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

postgres=#

Messaggio di errore

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?

Causa

Un client ha tentato una connessione all'indirizzo IP pubblico.

Nota:questo è un errore restituito al client, nell'esempio sopra psql. Nel caso di un'applicazione web, controllare il log degli errori del server web.

Risoluzione

Configura il servizio per l'ascolto sull'indirizzo IP pubblico:

Nota:come best practice usa alter system invece di modificare postgresql.conf. 

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

Il comando alter system ha modificato postgresql.auto.conf come mostrato di seguito:

--- 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'

Riavvia il servizio e prova:

[[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

Affronteremo questo errore nel prossimo argomento.

Messaggio di errore

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

Causa

Il servizio PostgreSQL in esecuzione sull'indirizzo IP 192.168.0.11 non è configurato per consentire all'utente webutente di connettersi all'app web del database.

Risoluzione

Modificare il file di accesso pg_hba.conf per consentire la connessione:

--- 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

Ricarica il servizio e prova:

[[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".

Messaggio di errore

ERROR:  syntax error at or near "grant"

Causa

Grant è una delle parole chiave riservate di PostgreSQL

Risoluzione

Le parole chiave riservate devono essere citate:

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

webapp=>

Messaggio di errore

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

Causa

Un client ha tentato di rimuovere la tabella cust con tabelle figlio.

Risoluzione

Rivedi SUGGERIMENTO nel file di registro:

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;

Messaggio di errore

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

Causa

Il file di registro rivela un tentativo di inserire un valore che non corrisponde al tipo di colonna:

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

Risoluzione

Questo è un errore lato applicazione che deve essere corretto dagli sviluppatori o se è stato avviato da un client come un DBA che esegue psql. Non è richiesta alcuna azione dal DBA di produzione, poiché anche il messaggio di errore completo è stato restituito al client.

Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

Revisione e monitoraggio dei registri

L'opzione più semplice è configurare PostgreSQL per utilizzare syslog tramite il parametro log_destination in modo che i log possano essere inviati al tuo sistema di registrazione centralizzato preferito (ad es. rsyslog) e quindi ulteriormente elaborati lì per avvisare su condizioni di errore specifiche.

Un altro strumento, che richiede una configurazione quasi nulla è tail_n_mail, che funziona in combinazione con il demone cron.

Ancora un altro strumento in questo elenco è pgBadger che viene fornito con un ricco set di opzioni per la creazione di report, la visualizzazione e l'analisi non solo dei file di registro PostgreSQL, ma anche delle informazioni registrate dal raccoglitore di statistiche.

Salendo sulla scala della complessità, l'organizzazione può trarre vantaggio dall'investimento del tempo e degli sforzi per configurare uno stack ELK, che utilizza il modulo Filebeat PostgreSQL per generare avvisi e report.

Conclusione

La revisione dei registri degli errori, la notifica di problemi critici e la disponibilità di un versatile sistema di gestione dei registri che aiuti nella risoluzione dei problemi è importante per mantenere un ambiente di database sano. Fortunatamente, PostgreSQL fornisce un ricco framework di gestione degli errori, che si riflette nella grande varietà di prodotti disponibili tra cui scegliere. I criteri per selezionare quelli più adatti a uno specifico ambiente devono includere non solo le caratteristiche del prodotto ma anche la competenza tecnica richiesta.