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:
-
Log ind som postgres-bruger:
[[email protected] ~]# su - postgres [[email protected] ~]$ psql psql (9.6.6) Type "help" for help. postgres=#
-
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
-
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 WhitepaperGennemgang 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.