sql >> Base de Datos >  >> RDS >> PostgreSQL

Cómo decodificar los registros de errores de PostgreSQL

El informe de errores de PostgreSQL sigue una guía de estilo destinada a proporcionar al administrador de la base de datos la información necesaria para solucionar problemas de manera eficiente. Los mensajes de error normalmente contienen una breve descripción, seguida de información detallada y una sugerencia, si corresponde, que sugiere la solución. Hay otros detalles finos, explicados en la guía, como el uso del tiempo pasado o presente para indicar si el error es temporal o permanente.

Tipos de errores y niveles de gravedad

Al informar errores, PostgreSQL también devolverá un código de error SQLSTATE, por lo que los errores se clasifican en varias clases. Al revisar la lista de clases, tenga en cuenta que PostgreSQL también registra el éxito y la advertencia en el registro de errores; eso se debe a que logging_collector, el proceso de PostgreSQL responsable del registro, envía todos los mensajes a stderr por defecto.

Cuando el recopilador de registro no se ha inicializado, los errores se registran en el registro del sistema. Por ejemplo, al intentar iniciar el servicio después de la instalación del paquete:

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

Cuando se devuelven mensajes de error a los clientes y, por lo tanto, se registran en el registro de errores, los mensajes se registran con un nivel de gravedad que se controla mediante el parámetro client_min_messages. El registro en los archivos de registro del servidor está controlado por el parámetro log_min_messages, mientras que log_min_error_statement permite el registro de declaraciones SQL que provocan un error de un nivel de gravedad específico.

PostgreSQL se puede configurar para iniciar sesión en los siguientes niveles de gravedad:

  • PÁNICO: Se cancelan todas las sesiones de la base de datos. Esta es una situación crítica que afecta a todos los clientes.
  • FATAL: La sesión actual se cancela debido a un error. El cliente puede volver a intentarlo. Otras bases de datos del clúster no se ven afectadas.
  • REGISTRO: Mensajes de funcionamiento normal.
  • ERROR: No ejecutar un comando. Este es un error permanente.
  • ADVERTENCIA: Un evento que, si bien no impide que se complete el comando, puede provocar fallas si no se aborda. El monitoreo de advertencias es una buena práctica en la detección temprana de problemas tanto en el servidor como en la aplicación.
  • AVISO: Información que los clientes pueden usar para mejorar su código.
  • INFORMACIÓN: Registros solicitados explícitamente por los clientes.
  • DEPURACIÓN1..DEPURACIÓN5: Información del desarrollador.

Nota:Los mensajes de nivel superior incluyen mensajes de niveles inferiores, es decir, establecer el nivel de registro en LOG le indicará a PostgreSQL que también registre mensajes FATAL y PÁNICO.

Errores comunes y cómo solucionarlos

Lo que sigue es una lista no exhaustiva:

Mensaje de error

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

Resolución

Verifique que el servicio PostgreSQL se esté ejecutando utilizando las herramientas del sistema operativo (ps, netstat, ss, systemctl) o verifique la presencia de postmaster.pid en el directorio de datos.

Mensaje de error

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

Causa

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

Resolución

El archivo de registro contendrá un mensaje más detallado a tal efecto:

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"

Sigue estos pasos:

  1. Inicie sesión como usuario de postgres:

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

postgres=#

  2. Realice el siguiente cambio en pg_hba.conf que permitirá que el usuario raíz inicie sesión sin contraseña:

    --- 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. Vuelva a cargar el servicio y pruebe:

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

postgres=#

Mensaje de error

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 cliente intentó conectarse a la dirección IP pública.

Nota:Este es un error devuelto al cliente, en el ejemplo anterior psql. En el caso de una aplicación web, consulte el registro de errores del servidor web.

Resolución

Configure el servicio para escuchar en la dirección IP pública:

Nota:Como práctica recomendada, use alterar el sistema en lugar de editar postgresql.conf. 

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

El comando alter system ha modificado postgresql.auto.conf como se muestra a continuación:

--- 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 el servicio y pruebe:

[[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 este error en el siguiente tema.

Mensaje de error

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

Causa

El servicio PostgreSQL que se ejecuta en la dirección IP 192.168.0.11 no está configurado para permitir que el usuario web se conecte a la aplicación web de la base de datos.

Resolución

Modifique el archivo de acceso pg_hba.conf para permitir la conexión:

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

Vuelva a cargar el servicio y pruebe:

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

Mensaje de error

ERROR:  syntax error at or near "grant"

Causa

Grant es una de las palabras clave reservadas de PostgreSQL

Resolución

Las palabras clave reservadas deben citarse:

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

webapp=>

Mensaje de error

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

Causa

Un cliente intentó eliminar la tabla personalizada que tiene tablas secundarias.

Resolución

Revise SUGERENCIA en el archivo de 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;

Mensaje de error

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

Causa

El archivo de registro revela un intento de insertar un valor que no coincide con el tipo de columna:

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

Resolución

Este es un error del lado de la aplicación que deben corregir los desarrolladores, o si lo inició un cliente como un DBA que ejecuta psql. El DBA de producción no requiere ninguna acción, ya que el mensaje de error completo también se devolvió al cliente.

Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

Revisión y seguimiento de registros

La opción más simple es configurar PostgreSQL para usar syslog a través del parámetro log_destination para que los registros puedan enviarse a su sistema de registro centralizado favorito (por ejemplo, rsyslog) y luego procesarse allí para alertar sobre condiciones de error específicas.

Otra herramienta que requiere una configuración casi nula es tail_n_mail, que funciona en combinación con el demonio cron.

Otra herramienta más en esta lista es pgBadger que viene con un amplio conjunto de opciones para generar informes, visualizar y analizar no solo los archivos de registro de PostgreSQL, sino también la información registrada por el recopilador de estadísticas.

Al ascender en la escala de complejidad, la organización puede beneficiarse de invertir tiempo y esfuerzo para configurar una pila ELK, que utiliza el módulo PostgreSQL de Filebeat para generar alertas e informes.

Conclusión

Revisar los registros de errores, recibir notificaciones sobre problemas críticos y tener un sistema de administración de registros versátil que ayude en la resolución de problemas es importante para mantener un entorno de base de datos saludable. Afortunadamente, PostgreSQL proporciona un rico marco de gestión de errores, que se refleja en la gran variedad de productos disponibles para elegir. Los criterios para seleccionar los que mejor se adapten a un entorno específico deben incluir no solo las características del producto sino también la experiencia técnica requerida.