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

Sådan afkodes PostgreSQL-fejlloggene

PostgreSQL-fejlrapportering følger en stilguide, der har til formål at give databaseadministratoren de nødvendige oplysninger til effektivt at fejlfinde problemer. Fejlmeddelelser indeholder normalt en kort beskrivelse efterfulgt af nogle detaljerede oplysninger og et tip, hvis det er relevant, der foreslår løsningen. Der er andre fine detaljer, forklaret i vejledningen, såsom brugen af ​​datid eller nutid for at angive, om fejlen er midlertidig eller permanent.

Fejltyper og sværhedsgrader

Ved indberetning af fejl vil PostgreSQL også returnere en SQLSTATE fejlkode, derfor klassificeres fejl i flere klasser. Når du gennemgår listen over klasser, skal du være opmærksom på, at succes og advarsel også logges af PostgreSQL til fejlloggen - det er fordi logging_collector, PostgreSQL-processen, der er ansvarlig for logning, sender alle meddelelser til stderr som standard.

Når logopsamleren ikke er initialiseret, logges fejl til systemloggen. For eksempel, når du forsøger at starte tjenesten efter pakkeinstallationen:

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

Når der returneres fejlmeddelelser til klienter, og derfor logges til fejllog, logges meddelelser med et alvorlighedsniveau, der styres ved hjælp af parameteren client_min_messages. Logning til serverlogfiler styres af parameteren log_min_messages, mens log_min_error_statement muliggør logning af SQL-sætninger, der forårsager en fejl af et bestemt sværhedsniveau.

PostgreSQL kan konfigureres til at logge på følgende sværhedsgrader:

  • PANIK: Alle databasesessioner afbrydes. Dette er en kritisk situation, der påvirker alle klienter.
  • FATALT: Den aktuelle session er afbrudt på grund af en fejl. Klienten kan prøve igen. Andre databaser i klyngen påvirkes ikke.
  • LOG: Normal driftsmeddelelser.
  • FEJL: Undladelse af at udføre en kommando. Dette er en permanent fejl.
  • ADVARSEL: En hændelse, der, selv om den ikke forhindrer kommandoen i at fuldføre, kan føre til fejl, hvis den ikke løses. Overvågning for advarsler er en god praksis i tidlig opdagelse af problemer på både server- og applikationssiden.
  • BEMÆRKNING: Oplysninger, som klienter kan bruge til at forbedre deres kode.
  • INFO: Logs, der er eksplicit anmodet af klienter.
  • DEBUG1..DEBUG5: Udvikleroplysninger.

Bemærk:Beskeder på højere niveau inkluderer meddelelser fra lavere niveauer, dvs. at indstille logningsniveauet til LOG, vil instruere PostgreSQL om også at logge FATAL- og PANIK-meddelelser.

Almindelige fejl og hvordan man løser dem

Det følgende er en ikke-udtømmende liste:

Fejlmeddelelse

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

Årsag

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

Opløsning

Bekræft, at PostgreSQL-tjenesten kører ved hjælp af operativsystemværktøjer (ps, netstat, ss, systemctl), eller kontroller for tilstedeværelsen af ​​postmaster.pid i databiblioteket.

Fejlmeddelelse

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

Årsag

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

Opløsning

Logfilen vil indeholde en mere detaljeret besked om dette:

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"

Følg disse trin:

  1. Log ind som postgres-bruger:

    [[email protected] ~]# su - postgres
    [[email protected] ~]$ psql
    psql (9.6.6)
    Type "help" for help.
    
    postgres=#
  2. Foretag følgende ændring til pg_hba.conf, der vil tillade root-brugeren at logge ind uden en adgangskode:

    --- 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. Genindlæs tjenesten og test:

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

Fejlmeddelelse

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?

Årsag

En klient forsøgte at oprette forbindelse til den offentlige IP-adresse.

Bemærk:Dette er en fejl returneret til klienten i eksemplet ovenfor psql. I tilfælde af en webapplikation skal du kontrollere webserverens fejllog.

Opløsning

Konfigurer tjenesten til at lytte på den offentlige IP-adresse:

Bemærk:Som en bedste praksis skal du bruge alter system i stedet for at redigere postgresql.conf.

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

Alter system-kommandoen har ændret postgresql.auto.conf som vist nedenfor:

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

Genstart tjenesten og test:

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

Vi behandler denne fejl i det næste emne.

Fejlmeddelelse

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

Årsag

PostgreSQL-tjenesten, der kører på IP-adressen 192.168.0.11, er ikke konfigureret til at tillade brugerens webbruger at oprette forbindelse til databasens webapp.

Opløsning

Rediger adgangsfilen pg_hba.conf for at tillade forbindelsen:

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

Genindlæs tjenesten og test:

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

Fejlmeddelelse

ERROR:  syntax error at or near "grant"

Årsag

Grant er et af de PostgreSQL reserverede søgeord

Opløsning

Reserverede søgeord skal citeres:

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

webapp=>

Fejlmeddelelse

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

Årsag

En klient forsøgte at fjerne den table cust, der har underordnede tabeller.

Opløsning

Gennemgå TIP i logfilen:

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;

Fejlmeddelelse

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

Årsag

Logfilen afslører et forsøg på at indsætte en værdi, der ikke matcher kolonnetypen:

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

Opløsning

Dette er en applikationssidefejl, som skal rettes af udviklere, eller hvis den blev initieret af en klient, såsom en DBA, der kører psql. Ingen handling er påkrævet af produktions-DBA, da den fulde fejlmeddelelse også blev returneret til klienten.

Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload Whitepaper

Gennemgang og overvågning af logfiler

Den mest enkle mulighed er at konfigurere PostgreSQL til at bruge syslog via parameteren log_destination, så logfiler kan sendes til dit foretrukne centraliserede logningssystem (f.eks. rsyslog) og derefter behandles yderligere der for at advare om specifikke fejltilstande.

Et andet værktøj, der kræver en tæt på ingen opsætning, er tail_n_mail, som fungerer i kombination med cron-dæmonen.

Endnu et værktøj på denne liste er pgBadger, der kommer med et rigt sæt muligheder for rapportering, visualisering og analyse af ikke kun PostgreSQL-logfilerne, men også de oplysninger, der er logget af statistikindsamleren.

Når man bevæger sig op på kompleksitetsskalaen, kan organisationen drage fordel af at investere tid og kræfter i at oprette en ELK-stak, som bruger Filebeat PostgreSQL-modulet til at generere advarsler og rapporter.

Konklusion

Gennemgang af fejllogfilerne, at blive underrettet om kritiske problemer og have et alsidigt logstyringssystem, der hjælper med fejlfinding, er vigtigt for at opretholde et sundt databasemiljø. Heldigvis giver PostgreSQL en rig fejlstyringsramme, der afspejles i det store udvalg af tilgængelige produkter at vælge imellem. Kriterierne for at vælge dem, der passer bedst til et specifikt miljø, skal ikke kun omfatte produktfunktionerne, men også den nødvendige tekniske ekspertise.


  1. Opret tabelvariabel i MySQL

  2. Sådan kalder du en Oracle PL/SQL-objekt supermetode

  3. Sådan bruger du flere databaser i Laravel

  4. NOT IN i postgresql virker ikke