Die PostgreSQL-Fehlerberichterstattung folgt einem Styleguide, der darauf abzielt, dem Datenbankadministrator die Informationen bereitzustellen, die für eine effiziente Problembehandlung erforderlich sind. Fehlermeldungen enthalten in der Regel eine kurze Beschreibung, gefolgt von einigen Detailinformationen und ggf. einem Hinweis zur Lösung. Es gibt weitere feine Details, die in der Anleitung erklärt werden, wie z. B. die Verwendung der Vergangenheits- oder Gegenwartsform, um anzuzeigen, ob der Fehler vorübergehend oder dauerhaft ist.
Fehlerarten und Schweregrade
Beim Melden von Fehlern gibt PostgreSQL auch einen SQLSTATE-Fehlercode zurück, daher werden Fehler in mehrere Klassen eingeteilt. Beachten Sie beim Überprüfen der Klassenliste, dass Erfolg und Warnung auch von PostgreSQL im Fehlerprotokoll protokolliert werden – das liegt daran, dass der für die Protokollierung zuständige PostgreSQL-Prozess Logging_collector alle Nachrichten an stderr sendet standardmäßig.
Wenn der Protokollkollektor nicht initialisiert wurde, werden Fehler im Systemprotokoll protokolliert. Wenn Sie beispielsweise versuchen, den Dienst nach der Paketinstallation zu starten:
[[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'.Beim Zurücksenden von Fehlermeldungen an Clients und daher beim Protokollieren im Fehlerprotokoll werden Nachrichten mit einem Schweregrad protokolliert, der mithilfe des Parameters client_min_messages gesteuert wird. Die Protokollierung in Serverprotokolldateien wird durch den Parameter log_min_messages gesteuert, während log_min_error_statement die Protokollierung von SQL-Anweisungen aktiviert, die einen Fehler mit einem bestimmten Schweregrad verursachen.
PostgreSQL kann so konfiguriert werden, dass es mit den folgenden Schweregraden protokolliert:
- PANIK: Alle Datenbanksitzungen werden abgebrochen. Dies ist eine kritische Situation, die alle Kunden betrifft.
- FATAL: Die aktuelle Sitzung wird aufgrund eines Fehlers abgebrochen. Der Client kann es erneut versuchen. Andere Datenbanken im Cluster sind nicht betroffen.
- LOG: Normale Betriebsmeldungen.
- FEHLER: Fehler beim Ausführen eines Befehls. Dies ist ein permanenter Fehler.
- WARNUNG: Ein Ereignis, das zwar nicht den Abschluss des Befehls verhindert, aber zu Fehlern führen kann, wenn es nicht behandelt wird. Die Überwachung auf Warnungen ist ein bewährtes Verfahren zur Früherkennung von Problemen sowohl auf Server- als auch auf Anwendungsseite.
- HINWEIS: Informationen, die Kunden verwenden können, um ihren Code zu verbessern.
- INFO: Protokolle, die ausdrücklich von Clients angefordert werden.
- DEBUG1..DEBUG5: Entwicklerinformationen.
Hinweis:Nachrichten auf höherer Ebene beinhalten Nachrichten von niedrigeren Ebenen, d. h. wenn Sie die Protokollierungsebene auf LOG setzen, wird PostgreSQL angewiesen, auch FATAL- und PANIC-Nachrichten zu protokollieren.
Häufige Fehler und wie man sie behebt
Es folgt eine nicht vollständige Liste:
Fehlermeldung
psql: could not connect to server: No such file or directoryUrsache
[[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"?Auflösung
Überprüfen Sie, ob der PostgreSQL-Dienst mit Betriebssystem-Tools (ps, netstat, ss, systemctl) ausgeführt wird, oder prüfen Sie, ob postmaster.pid im Datenverzeichnis vorhanden ist.
Fehlermeldung
psql: FATAL: Peer authentication failed for user "postgres"Ursache
[[email protected] ~]# psql -U postgres
psql: FATAL: Peer authentication failed for user "postgres"Auflösung
Die Protokolldatei enthält dazu eine ausführlichere Meldung:
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"Befolgen Sie diese Schritte:
-
Melden Sie sich als postgres-Benutzer an:
[[email protected] ~]# su - postgres [[email protected] ~]$ psql psql (9.6.6) Type "help" for help. postgres=# -
Nehmen Sie die folgende Änderung an pg_hba.conf vor, die es dem Root-Benutzer ermöglicht, sich ohne Passwort anzumelden:
--- 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 -
Laden Sie den Dienst neu und testen Sie:
[[email protected] ~]# psql -U postgres psql (9.6.6) Type "help" for help. postgres=#
Fehlermeldung
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?Ursache
Ein Client hat versucht, eine Verbindung zur öffentlichen IP-Adresse herzustellen.
Hinweis:Dies ist ein Fehler, der an den Client zurückgegeben wird, im obigen Beispiel psql. Überprüfen Sie im Falle einer Webanwendung das Fehlerprotokoll des Webservers.
Auflösung
Konfigurieren Sie den Dienst so, dass er die öffentliche IP-Adresse überwacht:
Hinweis:Verwenden Sie als bewährte Methode alter system, anstatt postgresql.conf zu bearbeiten.
postgres=# alter system set listen_addresses TO 'localhost,192.168.0.11';
ALTER SYSTEMDer Befehl alter system hat die postgresql.auto.conf wie unten gezeigt geändert:
--- 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'Starten Sie den Dienst neu und testen Sie:
[[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 offDieser Fehler wird im nächsten Thema behandelt.
Fehlermeldung
psql: FATAL: no pg_hba.conf entry for host "192.168.0.11", user "webuser", database "webapp", SSL offUrsache
Der PostgreSQL-Dienst, der auf der IP-Adresse 192.168.0.11 ausgeführt wird, ist nicht so konfiguriert, dass der Benutzer webuser eine Verbindung zur Datenbank webapp herstellen kann.
Auflösung
Ändern Sie die Zugriffsdatei pg_hba.conf, um die Verbindung zuzulassen:
--- 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 md5Laden Sie den Dienst neu und testen Sie:
[[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".Fehlermeldung
ERROR: syntax error at or near "grant"Ursache
Grant ist eines der reservierten PostgreSQL-Schlüsselwörter
Auflösung
Reservierte Schlüsselwörter müssen in Anführungszeichen gesetzt werden:
webapp=> create table "grant" (id numeric);
CREATE TABLE
And verify:
webapp=> \d "grant"
Table "public.grant"
Column | Type | Modifiers
--------+---------+-----------
id | numeric |
webapp=>Fehlermeldung
ERROR: cannot drop table cust because other objects depend on itUrsache
Ein Client hat versucht, die Tabelle cust mit untergeordneten Tabellen zu entfernen.
Auflösung
Überprüfen Sie den HINWEIS in der Protokolldatei:
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;Fehlermeldung
ERROR: invalid input syntax for type numeric: "b" at character 26Ursache
Die Protokolldatei zeigt einen Versuch, einen Wert einzufügen, der nicht mit dem Spaltentyp übereinstimmt:
ERROR: invalid input syntax for type numeric: "b" at character 26
STATEMENT: insert into cust values ('b', 2);Auflösung
Dies ist ein anwendungsseitiger Fehler, der von Entwicklern korrigiert werden muss oder wenn er von einem Client wie einem DBA initiiert wurde, der psql ausführt. Der Produktions-DBA muss nichts unternehmen, da die vollständige Fehlermeldung auch an den Client zurückgegeben wurde.
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunterÜberprüfen und Überwachen von Protokollen
Die einfachste Option ist die Konfiguration von PostgreSQL für die Verwendung von Syslog über den Parameter log_destination, sodass Protokolle an Ihr bevorzugtes zentralisiertes Protokollierungssystem (z. B. rsyslog) gesendet und dort dann weiterverarbeitet werden können, um bei bestimmten Fehlerbedingungen gewarnt zu werden.
Ein weiteres Tool, das fast keine Einrichtung erfordert, ist tail_n_mail, das in Kombination mit dem Cron-Daemon funktioniert.
Ein weiteres Tool in dieser Liste ist pgBadger, das mit zahlreichen Optionen zum Berichten, Visualisieren und Analysieren nicht nur der PostgreSQL-Protokolldateien, sondern auch der vom Statistiksammler protokollierten Informationen ausgestattet ist.
Wenn Sie auf der Komplexitätsskala aufsteigen, können Unternehmen davon profitieren, Zeit und Mühe in die Einrichtung eines ELK-Stacks zu investieren, der das Filebeat PostgreSQL-Modul verwendet, um Warnungen und Berichte zu generieren.
Schlussfolgerung
Die Überprüfung der Fehlerprotokolle, die Benachrichtigung bei kritischen Problemen und ein vielseitiges Protokollverwaltungssystem, das bei der Fehlerbehebung hilft, sind wichtig, um eine intakte Datenbankumgebung aufrechtzuerhalten. Glücklicherweise bietet PostgreSQL ein reichhaltiges Fehlermanagement-Framework, das sich in der großen Auswahl an verfügbaren Produkten widerspiegelt. Die Kriterien für die Auswahl der für eine bestimmte Umgebung am besten geeigneten Produkte müssen nicht nur die Produkteigenschaften, sondern auch das erforderliche technische Know-how umfassen.
