Как да декодирате журналите за грешки на PostgreSQL

Отчитането на грешки в PostgreSQL следва ръководство за стил, насочено към предоставяне на администратора на базата данни с информацията, необходима за ефективно отстраняване на проблеми. Съобщенията за грешки обикновено съдържат кратко описание, последвано от подробна информация и подсказка, ако е приложима, предлагаща решението. Има и други фини подробности, обяснени в ръководството, като например използването на минало или сегашно време, за да се посочи дали грешката е временна или постоянна.

Видове грешки и нива на сериозност

Когато съобщава за грешки, PostgreSQL също ще върне код за грешка SQLSTATE, поради което грешките се класифицират в няколко класа. Когато преглеждате списъка с класове, имайте предвид, че успехът и предупреждението също се записват от PostgreSQL в регистъра за грешки – това е защото logging_collector, процесът на PostgreSQL, отговорен за регистрирането, изпраща всички съобщения до stderr по подразбиране.

Когато колекторът за регистриране не е инициализиран, грешките се записват в системния дневник. Например, когато се опитвате да стартирате услугата след инсталирането на пакета:

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

Когато се връщат съобщения за грешки на клиенти и следователно се записват в регистъра за грешки, съобщенията се записват с ниво на сериозност, което се контролира с помощта на параметъра client_min_messages. Регистрирането в регистрационни файлове на сървъра се контролира от параметъра log_min_messages, докато log_min_error_statement позволява регистриране на SQL изрази, които причиняват грешка с определено ниво на сериозност.

PostgreSQL може да бъде конфигуриран да регистрира на следните нива на сериозност:

ПАНИКА: Всички сесии на база данни са прекратени. Това е критична ситуация, която засяга всички клиенти.
ФАТАЛНО: Текущата сесия е прекъсната поради грешка. Клиентът може да опита отново. Други бази данни в клъстера не са засегнати.
LOG: Съобщения за нормална работа.
ГРЕШКА: Неизпълнение на команда. Това е постоянна грешка.
ПРЕДУПРЕЖДЕНИЕ: Събитие, което, макар и да не възпрепятства изпълнението на командата, може да доведе до неуспехи, ако не бъде адресирано. Наблюдението за предупреждения е добра практика за ранно откриване на проблеми както от страна на сървъра, така и от страна на приложението.
ЗАБЕЛЕЖКА: Информация, която клиентите могат да използват, за да подобрят своя код.
ИНФОРМАЦИЯ: Регистри, изрично заявени от клиенти.
DEBUG1..DEBUG5: Информация за програмиста.

Забележка:Съобщенията от по-високо ниво включват съобщения от по-ниски нива, т.е. задаване на нивото на регистриране на LOG, ще инструктира PostgreSQL също да регистрира FATAL и PANIC съобщения.

Чести грешки и как да ги поправим

Това, което следва, е неизчерпателен списък:

Съобщение за грешка

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

Причина

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

Разделителна способност

Проверете дали услугата PostgreSQL работи, като използвате инструменти на операционната система (ps, netstat, ss, systemctl) или проверете за наличието на postmaster.pid в директорията с данни.

Съобщение за грешка

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

Причина

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

Разделителна способност

Регистрационният файл ще съдържа по-подробно съобщение в този смисъл:

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"

Следвайте тези стъпки:

Влезте като потребител на postgres:

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

postgres=#

Направете следната промяна в pg_hba.conf, която ще позволи на root потребителя да влезе без парола:

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

Презаредете услугата и тествайте:

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

postgres=#

Съобщение за грешка

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?

Причина

Клиент се опита да се свърже с публичния IP адрес.

Забележка:Това е грешка, върната на клиента, в примера по-горе psql. В случай на уеб приложение проверете регистъра за грешки на уеб сървъра.

Разделителна способност

Конфигурирайте услугата да слуша на публичния IP адрес:

Забележка:Като най-добра практика използвайте alter system, вместо да редактирате postgresql.conf.

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

Командата alter system е променила postgresql.auto.conf, както е показано по-долу:

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

Рестартирайте услугата и тествайте:

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

Ще разгледаме тази грешка в следващата тема.

Съобщение за грешка

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

Причина

Услугата PostgreSQL, работеща на IP адрес 192.168.0.11, не е конфигурирана да позволява на потребителя уеб потребител да се свърже с уеб приложението на базата данни.

Разделителна способност

Променете файла за достъп pg_hba.conf, за да разрешите връзката:

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

Презаредете услугата и тествайте:

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

Съобщение за грешка

ERROR:  syntax error at or near "grant"

Причина

Grant е една от запазените ключови думи на PostgreSQL

Разделителна способност

Запазените ключови думи трябва да бъдат цитирани:

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

webapp=>

Съобщение за грешка

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

Причина

Клиент се опита да премахне таблицата cust, която има дъщерни таблици.

Разделителна способност

Прегледайте HINT в регистрационния файл:

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;

Съобщение за грешка

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

Причина

Регистрационният файл разкрива опит за вмъкване на стойност, която не съответства на типа колона:

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

Разделителна способност

Това е грешка от страна на приложението, която трябва да бъде коригирана от разработчиците или ако е инициирана от клиент, като например DBA, изпълняващ psql. Производственият DBA не изисква действие, тъй като пълното съобщение за грешка също беше върнато на клиента.

Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга

Регистъри за преглед и наблюдение

Най-простата опция е да конфигурирате PostgreSQL да използва syslog чрез параметъра log_destination, така че регистрационните файлове да могат да се изпращат до любимата ви централизирана система за регистриране (напр. rsyslog) и след това да се обработват допълнително там за предупреждаване при специфични условия за грешка.

Друг инструмент, който изисква настройка почти нищо, е tail_n_mail, който работи в комбинация с демона cron.

Още един инструмент в този списък е pgBadger, който се предлага с богат набор от опции за отчитане, визуализиране и анализиране не само на регистрационните файлове на PostgreSQL, но и на информацията, регистрирана от колектора на статистически данни.

Придвижвайки се нагоре по скалата на сложността, организацията може да се възползва от инвестирането на време и усилия за настройване на стек ELK, който използва модула Filebeat PostgreSQL за генериране на сигнали и отчети.

Заключение

Прегледът на регистрационните файлове за грешки, уведомяването за критични проблеми и наличието на гъвкава система за управление на регистрационни файлове, която помага при отстраняване на неизправности, е важно за поддържането на здравословна среда на база данни. За щастие, PostgreSQL предоставя богата рамка за управление на грешки, отразена в голямото разнообразие от налични продукти, от които да избирате. Критериите за избор на тези, които най-добре отговарят на конкретна среда, трябва да включват не само характеристиките на продукта, но и необходимия технически опит.