Jak zdekodować dzienniki błędów PostgreSQL

Raportowanie błędów PostgreSQL jest zgodne z przewodnikiem stylu, mającym na celu dostarczenie administratorowi bazy danych informacji wymaganych do skutecznego rozwiązywania problemów. Komunikaty o błędach zwykle zawierają krótki opis, po którym następują szczegółowe informacje i wskazówkę, jeśli dotyczy, sugerującą rozwiązanie. Istnieją inne drobne szczegóły wyjaśnione w przewodniku, takie jak użycie czasu przeszłego lub teraźniejszego do wskazania, czy błąd jest tymczasowy, czy trwały.

Rodzaje błędów i poziomy ważności

Podczas zgłaszania błędów PostgreSQL zwróci również kod błędu SQLSTATE, dlatego błędy są podzielone na kilka klas. Przeglądając listę klas, zauważ, że sukces i ostrzeżenie są również rejestrowane przez PostgreSQL w dzienniku błędów — to dlatego, że logging_collector, proces PostgreSQL odpowiedzialny za rejestrowanie, wysyła wszystkie komunikaty do stderr domyślnie.

Jeśli kolektor rejestrowania nie został zainicjowany, błędy są rejestrowane w dzienniku systemowym. Na przykład podczas próby uruchomienia usługi po instalacji pakietu:

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

Podczas zwracania komunikatów o błędach do klientów, a tym samym rejestrowania w dzienniku błędów, komunikaty są rejestrowane z poziomem ważności kontrolowanym za pomocą parametru client_min_messages. Rejestrowanie do plików dziennika serwera jest kontrolowane przez parametr log_min_messages, natomiast log_min_error_statement umożliwia rejestrowanie instrukcji SQL, które powodują błąd o określonym poziomie ważności.

PostgreSQL można skonfigurować tak, aby logował się na następujących poziomach ważności:

PANIKA: Wszystkie sesje bazy danych są przerywane. To krytyczna sytuacja, która dotyka wszystkich klientów.
KRYTYCZNE: Bieżąca sesja została przerwana z powodu błędu. Klient może ponowić próbę. Nie ma to wpływu na inne bazy danych w klastrze.
DZIENNIK: Komunikaty dotyczące normalnego działania.
BŁĄD: Niewykonanie polecenia. To jest stały błąd.
OSTRZEŻENIE: Zdarzenie, które, chociaż nie uniemożliwia wykonania polecenia, może prowadzić do niepowodzeń, jeśli nie zostanie rozwiązane. Monitorowanie ostrzeżeń jest dobrą praktyką we wczesnym wykrywaniu problemów zarówno po stronie serwera, jak i aplikacji.
UWAGA: Informacje, które klienci mogą wykorzystać do ulepszenia swojego kodu.
INFORMACJE: Logi wyraźnie wymagane przez klientów.
DEBUG1..DEBUG5: Informacje dla programistów.

Uwaga:Komunikaty wyższego poziomu zawierają komunikaty z niższych poziomów, tj. ustawienie poziomu rejestrowania na LOG, poinstruuje PostgreSQL, aby rejestrował również komunikaty FATAL i PANIC.

Typowe błędy i sposoby ich naprawy

Poniżej znajduje się niewyczerpująca lista:

Komunikat o błędzie

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

Przyczyna

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

Rozdzielczość

Sprawdź, czy usługa PostgreSQL działa za pomocą narzędzi systemu operacyjnego (ps, netstat, ss, systemctl) lub sprawdź obecność postmaster.pid w katalogu danych.

Komunikat o błędzie

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

Przyczyna

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

Rozdzielczość

Plik dziennika będzie zawierał bardziej szczegółowy komunikat:

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"

Wykonaj następujące kroki:

Zaloguj się jako użytkownik postgres:

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

postgres=#

Wprowadź następującą zmianę w pg_hba.conf, która pozwoli użytkownikowi root zalogować się bez hasł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

Załaduj ponownie usługę i przetestuj:

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

postgres=#

Komunikat o błędzie

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?

Przyczyna

Klient próbował połączyć się z publicznym adresem IP.

Uwaga:To jest błąd zwracany do klienta, w powyższym przykładzie psql. W przypadku aplikacji internetowej sprawdź dziennik błędów serwera sieciowego.

Rozdzielczość

Skonfiguruj usługę do nasłuchiwania na publicznym adresie IP:

Uwaga:najlepszym rozwiązaniem jest użycie alter system zamiast edytowania postgresql.conf.

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

Polecenie alter system zmodyfikowało plik postgresql.auto.conf, jak pokazano poniżej:

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

Uruchom ponownie usługę i przetestuj:

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

Ten błąd zajmiemy się w następnym temacie.

Komunikat o błędzie

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

Przyczyna

Usługa PostgreSQL działająca pod adresem IP 192.168.0.11 nie jest skonfigurowana, aby umożliwić użytkownikowi sieciowemu połączenie się z aplikacją internetową bazy danych.

Rozdzielczość

Zmodyfikuj plik dostępu pg_hba.conf, aby umożliwić połączenie:

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

Załaduj ponownie usługę i przetestuj:

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

Komunikat o błędzie

ERROR:  syntax error at or near "grant"

Przyczyna

Grant jest jednym z zarezerwowanych słów kluczowych PostgreSQL

Rozdzielczość

Zarezerwowane słowa kluczowe muszą być cytowane:

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

webapp=>

Komunikat o błędzie

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

Przyczyna

Klient próbował usunąć cust tabeli, który ma tabele podrzędne.

Rozdzielczość

Sprawdź WSKAZÓWKA w pliku dziennika:

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;

Komunikat o błędzie

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

Przyczyna

Plik dziennika ujawnia próbę wstawienia wartości, która nie pasuje do typu kolumny:

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

Rozdzielczość

Jest to błąd po stronie aplikacji, który musi zostać naprawiony przez programistów lub jeśli został zainicjowany przez klienta, takiego jak DBA z uruchomionym psql. Produkcyjny administrator DBA nie wymaga żadnych działań, ponieważ pełny komunikat o błędzie został również zwrócony do klienta.

Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokument

Przeglądanie i monitorowanie dzienników

Najprostszą opcją jest skonfigurowanie PostgreSQL tak, aby używał syslog za pomocą parametru log_destination, dzięki czemu logi mogą być przesyłane do Twojego ulubionego scentralizowanego systemu rejestrowania (np. rsyslog), a następnie dalej przetwarzane w celu ostrzegania o określonych błędach.

Innym narzędziem, które nie wymaga prawie żadnej konfiguracji, jest tail_n_mail, który działa w połączeniu z demonem cron.

Jeszcze innym narzędziem na tej liście jest pgBadger, który zawiera bogaty zestaw opcji raportowania, wizualizacji i analizowania nie tylko plików dziennika PostgreSQL, ale także informacji rejestrowanych przez kolektor statystyk.

Przechodząc na skalę złożoności, organizacja może skorzystać na zainwestowaniu czasu i wysiłku w skonfigurowanie stosu ELK, który wykorzystuje moduł Filebeat PostgreSQL do generowania alertów i raportów.

Wniosek

Przeglądanie dzienników błędów, otrzymywanie powiadomień o krytycznych problemach i posiadanie wszechstronnego systemu zarządzania dziennikami, który pomaga w rozwiązywaniu problemów, jest ważne dla utrzymania zdrowego środowiska bazy danych. Na szczęście PostgreSQL zapewnia bogaty framework do zarządzania błędami, co znajduje odzwierciedlenie w dużej różnorodności dostępnych produktów do wyboru. Kryteria wyboru tych, które najlepiej pasują do konkretnego środowiska, muszą obejmować nie tylko cechy produktu, ale także wymaganą wiedzę techniczną.