PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Como decodificar os logs de erro do PostgreSQL


O relatório de erros do PostgreSQL segue um guia de estilo destinado a fornecer ao administrador do banco de dados as informações necessárias para solucionar problemas com eficiência. As mensagens de erro normalmente contêm uma breve descrição, seguida de algumas informações detalhadas e uma dica, se aplicável, sugerindo a solução. Existem outros detalhes, explicados no guia, como o uso do tempo passado ou presente para indicar se o erro é temporário ou permanente.

Tipos de erros e níveis de gravidade


Ao relatar erros, o PostgreSQL também retornará um código de erro SQLSTATE, portanto, os erros são classificados em várias classes. Ao revisar a lista de classes, observe que o sucesso e o aviso também são registrados pelo PostgreSQL no log de erros — isso porque logging_collector, o processo do PostgreSQL responsável pelo log, envia todas as mensagens para stderr por padrão.

Quando o coletor de log não foi inicializado, os erros são registrados no log do sistema. Por exemplo, ao tentar iniciar o serviço após a instalação do pacote:
[[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'.

Ao retornar mensagens de erro para clientes e, portanto, registrar no log de erros, as mensagens são registradas com um nível de gravidade controlado usando o parâmetro client_min_messages. O log nos arquivos de log do servidor é controlado pelo parâmetro log_min_messages, enquanto o log_min_error_statement permite o log de instruções SQL que causam um erro de um nível de gravidade específico.

O PostgreSQL pode ser configurado para registrar nos seguintes níveis de gravidade:
  • PÂNICO: Todas as sessões de banco de dados são abortadas. Esta é uma situação crítica que afeta todos os clientes.
  • FATAL: A sessão atual é abortada devido a um erro. O cliente pode tentar novamente. Outros bancos de dados no cluster não são afetados.
  • LOG: Mensagens de operação normal.
  • ERRO: Falha ao executar um comando. Este é um erro permanente.
  • AVISO: Um evento que, embora não impeça a conclusão do comando, pode levar a falhas se não for resolvido. O monitoramento de avisos é uma boa prática na detecção precoce de problemas no servidor e no aplicativo.
  • AVISO: Informações que os clientes podem usar para melhorar seu código.
  • INFORMAÇÕES: Registros solicitados explicitamente pelos clientes.
  • DEBUG1..DEBUG5: Informações do desenvolvedor.

Nota:As mensagens de nível superior incluem mensagens de níveis inferiores, ou seja, definir o nível de registro como LOG, instruirá o PostgreSQL a também registrar mensagens FATAL e PANIC.

Erros comuns e como corrigi-los


O que se segue é uma lista não exaustiva:

Mensagem de erro

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

Resolução


Verifique se o serviço PostgreSQL está sendo executado usando as ferramentas do sistema operacional (ps, netstat, ss, systemctl) ou verifique a presença de postmaster.pid no diretório de dados.

Mensagem de erro

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

Causa

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

Resolução


O arquivo de log conterá uma mensagem mais detalhada para esse efeito:
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"

Siga esses passos:

  1. Faça login como usuário postgres:
    [[email protected] ~]# su - postgres
[[email protected] ~]$ psql
psql (9.6.6)
Type "help" for help.

postgres=#

  2. Faça a seguinte alteração no pg_hba.conf que permitirá que o usuário root faça login sem uma senha:
    --- 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. Recarregue o serviço e teste:
    [[email protected] ~]# psql -U postgres
psql (9.6.6)
Type "help" for help.

postgres=#

Mensagem de erro

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


Um cliente tentou uma conexão com o endereço IP público.

Nota:Este é um erro retornado ao cliente, no exemplo acima psql. No caso de um aplicativo da web, verifique o log de erros do servidor da web.

Resolução


Configure o serviço para escutar no endereço IP público:

Observação:como prática recomendada, use alter system em vez de editar postgresql.conf. 
postgres=# alter system set listen_addresses TO 'localhost,192.168.0.11';
ALTER SYSTEM

O comando alter system modificou o postgresql.auto.conf conforme mostrado abaixo:
--- 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'

Reinicie o serviço e teste:
[[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

Abordaremos esse erro no próximo tópico.

Mensagem de erro

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

Causa


O serviço PostgreSQL executado no endereço IP 192.168.0.11 não está configurado para permitir que o usuário webuser se conecte ao banco de dados webapp.

Resolução


Modifique o arquivo de acesso pg_hba.conf para permitir a conexão:
--- 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

Recarregue o serviço e teste:
[[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".

Mensagem de erro

ERROR:  syntax error at or near "grant"

Causa


Grant é uma das palavras-chave reservadas do PostgreSQL

Resolução


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

webapp=>

Mensagem de erro

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

Causa


Um cliente tentou remover a tabela cust que possui tabelas filhas.

Resolução


Revise a DICA no arquivo de log:
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;

Mensagem de erro

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

Causa


O arquivo de log revela uma tentativa de inserir um valor que não corresponde ao tipo de coluna:
ERROR:  invalid input syntax for type numeric: "b" at character 26
STATEMENT:  insert into cust values ('b', 2);

Resolução


Este é um erro do lado do aplicativo que deve ser corrigido pelos desenvolvedores ou se foi iniciado por um cliente, como um DBA executando o psql. Nenhuma ação é exigida pelo DBA de produção, pois a mensagem de erro completa também foi retornada ao cliente.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

Revisando e monitorando registros


A opção mais simples é configurar o PostgreSQL para usar o syslog por meio do parâmetro log_destination para que os logs possam ser enviados para seu sistema de log centralizado favorito (por exemplo, rsyslog) e depois processados ​​para alertar sobre condições de erro específicas.

Outra ferramenta que requer quase nenhuma configuração é tail_n_mail, que funciona em combinação com o daemon cron.

Outra ferramenta nesta lista é o pgBadger que vem com um rico conjunto de opções para relatórios, visualização e análise não apenas dos arquivos de log do PostgreSQL, mas também das informações registradas pelo coletor de estatísticas.

Subindo na escala de complexidade, a organização pode se beneficiar investindo tempo e esforço para configurar uma pilha ELK, que usa o módulo Filebeat PostgreSQL para gerar alertas e relatórios.

Conclusão


Revisar os logs de erros, ser notificado sobre problemas críticos e ter um sistema de gerenciamento de logs versátil que auxilia na solução de problemas é importante para manter um ambiente de banco de dados saudável. Felizmente, o PostgreSQL oferece uma rica estrutura de gerenciamento de erros, refletida na grande variedade de produtos disponíveis para escolha. Os critérios para selecionar os que melhor se adequam a um ambiente específico devem incluir não apenas as características do produto, mas também o conhecimento técnico necessário.