Часто встречающиеся проблемы и пути их устранения#

Проблема:

Если включено расширение pg_pathman, pg_repack входит в бесконечный цикл при обработке его таблиц, что приводит к реорганизации не отдельной таблицы, а всей базы.

Решение:

Явно исключить pg_pathman из обработки с помощью ключа: -C pg_pathman.

Проблема:

При работе pg_bouncer в транзакционном режиме может наблюдаться ошибка:

ERROR: prepared statement "S_2" does not exist

Решение:

В качестве временного решения рекомендуется, до момента устранения данного ограничения, либо:

отключить prepare statement;
включить сессионный режим pgBouncer;
выставить prepareThreshold=0 в параметры jdbc (возможно увеличение latency). Пример строки подключения JDBC:
```
JDBC:postgresql:127.0.0.1:6543/dbname?prepareThreshold=0
```

Дополнительно: рекомендуется завершать открытые соединения в случае если они не используются.

Проблема:

СУБД не переключилась в режим резервного копирования (РК).

pg_is_in_backup
-----------------
f

Процессы РК не запустились. На стороне СРК ошибки:

[Critical] From: <E-mail> "<Host>"  Time: 7/24/2022 22:53:13
      04_manage_backup.sh on host <Host>
      Script execution timed out => aborted by the Session Manager
 
[Critical] From: <E-mail> "<Host>"  Time: 7/24/2022 22:53:13
      Session remote exec script "04_manage_backup.sh start"
      on host <Host> failed.
 
[Critical] From: <E-mail> "<Host>"  Time: 7/24/2022 22:53:13
      None of the Disk Agents completed successfully.
      Session has failed.

Из /var/log/messages:

Jul 24 22:23:13 pvlad-sverk0001 xinetd[1400]: START: omni pid=2697897 from=<IP-адрес>

Решение:

Возможно, БД находится в режиме неисключительной резервной копии до сих пор. Если это так, то:

стоит вывести ее из режима pg_stop_backup(false). И настроить для контрольных точек параметр checkpoint_timeout, чтобы они выполнялись не реже 10-15 минут;
или поправить скрипт, где разрешить pg_start_backup выполнять дополнительную контрольную точку:
```
pg_start_backup ( '<текст>', TRUE, FALSE )
```

Проблема:

Администраторы АС грузят раз в сутки большой объем данных и у Postgres заканчивается оперативная память.

Решение:

Уменьшить work_mem — это позволит не выбиваться за пределы памяти.

Проблема:

Потеря соединений с БД. Из лога pgbouncer:

2022-07-12 12:15:01.824 MSK [2310345] WARNING C-0x7f9b50ab0838 (328863): (nodb)/aposs_adm@10.55.193.90:37576 authentication context expired. user: db=aposs user=aposs_adm
2022-07-12 12:15:01.824 MSK AUDIT aposs/aposs_adm@10.55.193.90:37576 login attempt tls=no
2022-07-12 12:15:01.825 MSK AUDIT aposs/aposs_adm@10.55.193.90:37576 send auth startup packet
2022-07-12 12:15:01.895 MSK AUDIT aposs/aposs_adm@10.55.193.90:37576 auth server login ok
2022-07-12 12:15:41.512 MSK [2310345] LOG stats: 53 xacts/s, 97 queries/s, in 45910 B/s, out 19511 B/s, xact 1097 us, query 424 us, wait 0 us
2022-07-12 12:16:05.629 MSK AUDIT aposs/aposs_adm@10.55.193.90:33094 closing because: client close request (age=545s)
2022-07-12 12:16:41.512 MSK [2310345] LOG stats: 53 xacts/s, 97 queries/s, in 45956 B/s, out 19530 B/s, xact 1126 us, query 427 us, wait 10 us
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@10.55.192.224:39996 closing because: client unexpected eof (age=3298s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@10.55.192.224:33728 closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@10.55.192.224:33726 closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@10.55.192.224:33724 closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:30.658 MSK AUDIT aposs/aposs_adm@10.55.167.88:43240 connection received

Причины:

В логе очень много сообщений вида:
```
AUDIT aposs/aposs_adm@10.55.109.205:41658 closing because: client unexpected eof (age=1815s)
```
Данное сообщение свидетельствует о том, что pgbouncer обнаружил отсутствие клиента с противоположной стороны. Возможно, это обрывы сети, но вероятнее некорректное закрытие приложения (без закрытия пула соединений).
По причине 1 появляются сообщения вида:
```
AUDIT aposs/aposs_adm@10.55.186.214:5433 closing because: unclean server (age=1564s)
```
Данные события происходят когда теряется связь между клиентом и pgbouncer в момент передачи запроса, либо результатов запроса (pgbouncer закрывает ставшую ненужной сессию в которой могли остаться незафиксированные изменения). Данное событие является прямым следствием причины 1.
В логе периодически встречаются сообщения вида:
```
AUDIT aposs/aposs_adm@10.55.186.214:5433 closing because: server_lifetime (age=3600s)
```
Данное сообщение говорит о том, что pgbouncer закрыл соединение по достижению параметра по умолчанию server_lifetime. Данное событие может приводить к причине 1 (например, приложение написано так, что падает при обрыве сессии).

Решение:

В первую очередь нужно понять почему происходит падение приложения (причина 1). Штатно ли закрываются пулы хикари или нет.

Дополнительно можно увеличить параметр server_lifetime pgbouncer до 7200s и явно задать параметр maxLifetime в хикари (например 1800s). Параметр maxLifeTime в хикари определяет время жизни соединения, после которого его нужно пересоздать (касается только неактивных соединений, поэтому, если есть длинные транзакции, нужно определить максимальное время их выполнения и задать выше этого времени параметр server_lifetime pgbouncer).

Проблема:

При работе с хранилищем паролей (утилита pg_auth_config), а именно при удалении записи (remove) или очистке хранилища паролей (reset) возникает ошибка:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

Решение:

Запустите выполнение команды с ключом -s (без подтверждения операции):

-- Удаление записи из хранилища паролей
pg_auth_config  remove -s -h <host> -p 5433 -U <username> -d <database>

Проблема:

Для транзакций не имеющих флаг READ ONLY при выполнении DML на мастер-узле возникают ошибки вида

ERROR:  cannot execute UPDATE in a read-only transaction

Причины:

PgBouncer в транзакционном режиме по умолчанию не сбрасывает настройки сессии в сторону БД. Как результат может возникает ситуация, когда RW транзакция попадает в сессию с параметрами для RO транзакции.

Решение:

Настройте принудительный сброс параметров для сессий в pgBouncer. Для этого добавьте/скорректиройте следующие параметры:
```
$ grep server_reset_query /etc/pgbouncer/pgbouncer.ini
server_reset_query_always = 1
server_reset_query = DISCARD ALL
```

Внимание!

В этом случае будут сбрасываться все параметры сессии, в том числе search_path, set role и т.д.

Примените настройки:
```
sudo systemctl reload pgbouncer
```

Проблема:

Pgbouncer блокирует УЗ при включенной сквозной аутентификации.

Решение:

Компенсационные меры:

Создайте bash скрипт c текстом sudo systemctl restart pgbouncer и с именем reload_pgbouncer.sh, поместите его в каталог /etc/patroni/. В файле конфигурации postgres.yml, в разделе postgresql: добавьте следующую строку:
```
callbacks:
on_restart: /etc/patroni/reload_pgbouncer.sh
```
В результате после перезагрузки экземпляра СУБД, Patroni выполнит скрипт reload_pgbouncer.sh, который перезагрузит PgBouncer и соответственно токен клиента обновится.
Обходное решение:

Отключите использование сквозной аутентификации.

Проблема:

Не работает аутентификация по сертификатам, если не настроен TLS.

Пример:

Ошибка при подключении через SSL (сертификаты) к порту 6544 (PgBouncer). При этом получается подключиться напрямую в Pangolin к порту 5433, пароль не проверяется и устанавливается зашифрованное соединение:
```
[postgres@host /home/postgres]$ psql -p 5433 -U postgres

psql (11.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=#
```
Аутентификация по порту 6544 (через pgBouncer) прошла неуспешно. Соединение не установлено:
```
[postgres@host /home/postgres]$ psql -p 6544 -U postgres
psql: ERROR: authentication failed for user "postgres": host rejected
```

Лог PgBouncer пишет следующее:

2021-12-29 11:22:54.889 MSK AUDIT postgres/postgres@10.53.126.216:46156 login attempt tls=no
2021-12-29 11:22:54.889 MSK AUDIT postgres/(nouser)@10.53.126.216:5544 new connection to auth server (from 10.53.126.216:46948)
2021-12-29 11:22:54.897 MSK AUDIT postgres/postgres@10.53.126.216:46156 send auth startup packet
2021-12-29 11:22:54.948 MSK AUDIT postgres/postgres@10.53.126.216:46156 auth server login failed
2021-12-29 11:22:54.948 MSK AUDIT postgres/postgres@10.53.126.216:46156 closing because: authentication failed for user "postgres": host rejected (age=0s)
2021-12-29 11:22:54.948 MSK [3254560] WARNING C-0xabe600 (2): postgres/postgres@10.53.126.216:46156 pooler error: authentication failed for user "postgres": host rejected

Решение:

Решением является настройка TLS параметров соединения между PgBouncer и Pangolin в файле конфигурации pgbouncer.ini. А именно необходимо раскомментировать все строчки под TLS SETTINGS, указать пути до актуальных сертификатов.

Проблема:

Файловая система /pgarclogs заполнена на 100%.

Решение:

Очистите каталог /pgarclogs/wal/clustername (в случае длительной недоступности каталога архивов часть wal-файлов гарантированно потеряется и восстановиться с их помощью уже не будет возможности);
Убедитесь, что новые архивы создаются, сессии бэкапа wal-архивов периодически отрабатывают и чистят каталог;
Выполните полное копирование (Full Backup).

В случае, если закончится место в pgarchlogs, начнет заполняться каталог pg_xlog. По переполнению каталога pg_xlog, СУБД аварийно завершит свою работу.

Проблема:

Все соединения с БД завершаются по причине client_login_timeout:

2022-08-17 19:47:53.155 MSK [1347149] DEBUG C-0x1b0c040 (32): ufs/aplj@172.20.2.214:33131 client_proto: evtype = FLUSH, state = CL_LOGIN
2022-08-17 19:47:53.155 MSK [1347149] LOG C-0x1b076a0 (1): ufs/aplj@172.20.2.242:30229 closing because: client_login_timeout (age=177s)
2022-08-17 19:47:53.155 MSK [1347149] WARNING C-0x1b076a0 (1): ufs/aplj@172.20.2.242:30229 pooler error: client_login_timeout

Решение:

Вынесите изменения в код pgbouncer, в дальнейшем функция fill_remote_hostname будет вызываться только тогда, когда включена поддержка двухфакторной аутентификацией.

Проблема:

При разблокировке пользователя в однопользовательском режиме возникает ошибка:

ERROR: Can't find role with Oid <roloid> in password policy cache

Решение:

Выполните команду:

backend> update pg_pp_policy set lockout='f' WHERE roloid = to_regrole('postgres');

Для выхода из однопользовательского режима нажмите Crl-D.

Проблема:

Заблокированы все администраторы. В случае блокировки всех администраторов БД, в том числе пользователя postgres, восстановить УЗ функцией unblock_role не получится, так как все пользователи с правами на ее запуск не могут подключиться к БД.

В такой ситуации patroni не сможет подключиться к экземпляру postgres и кластер потеряет лидера. Это можно увидеть в таблице вывода: столбец Role будет пустой.

$ list
+ Cluster: clustername (6857170778029161231) ----------------------------------------+--------------+---------+----+-----------+
|                 Member                |                    Host                    |     Role     |  State  | TL | Lag in MB |
+---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+
| <host>                                | <host>:5433                                |              | running |    |   unknown |
| <host>                                | <host>:5433                                |              | running |    |   unknown |
+---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+

В логе patroni появится запись об ошибке:

psycopg2.OperationalError: FATAL: Password policy. Auth check. User blocked: too many login fails
...
INFO: Error communicating with PostgreSQL. Will try again later

Решение:

Для разблокировки и восстановления работы кластера необходимо последовательно выполнить следующие действия:

Определить, на каком хосте был последний активный лидер.
Остановить службу Patroni на хосте последнего лидера.
Запустить PostgreSQL в single user режиме.
В single режиме разблокировать пользователя postgres.
Запустить службу Patroni.
Проверить работоспособность кластера.
Разблокировать остальных администраторов БД стандартным образом.

Проблемы, которые могут возникнуть при работе с PgBouncer#

Примечание:

Расшифровка C-0x15b4c60 и аналогичных сообщений - это комбинация информации о типе соединения (С-между клиентом и pgbouncer; S-между сервером и pgbouncer; A-между процессом аутентификации и pgbouncer) и адреса структуры.

Ошибки (Errors)#

Действия при возникновении описанных в данном разделе ошибок идентичны и описаны в следующем параграфе.

Проблема:

ERROR C-0x15b4c60 (1): database/username@127.0.0.1:45208 set_pool(): failed to allocate new user

Причина:

Нехватка памяти для создания структуры с целью хранения данных пользователя, для которого осуществляется сквозная аутентификация.

Проблема:

ERROR C-0x15b4c60 (1): database/username@127.0.0.1:45208 unknown client

Причина:

Передача в метод update_last_auth_session или в метод set_auth_inactivity_period структуры, у которой не задано свойство login_user.

Проблема:

ERROR A-0x6f3480 (1): database/(nouser)@127.0.0.1:6667 unknown pkt from server: '!'

Причина:

При соединении с процессом, отвечающим за проведение сквозной аутентификации, получен пакет не известного типа.

Проблема:

ERROR A-0x6f3480 (1): database/(nouser)@127.0.0.1:6667 unknown pkt from server: '!'

Причина:

При передаче в метод update_last_auth_session или в метод set_auth_inactivity_period передана структура, у которой не задано свойство login_user.

Действия в случае ошибок PgBouncer#

Для сбора диагностической информации:

установка параметра файла postgresql.conf log_min_messages в значение DEBUG5;
установка параметр файла pgbouncer.ini verbose в значение 2.

Собранную информацию необходимо передать в поддержку.

Предупреждения (Warnings)#

Проблема:

WARNING C-0x1e95410 (2): (nodb)/username@127.0.0.1:45454 authentication context expired. user: db=database user=username

Причина:

С момента предыдущей аутентификации пользователя прошло больше времени, чем задано в параметре auth_activity_period, определенном в postgresql.conf.

Решение:

Необходимо уменьшить промежуток между новыми соединениями данного пользователя к базе данных, или увеличить значение параметра auth_activity_period.

Проблема:

WARNING C-0x1e95410 (2): database/username@127.0.0.1:45454 Parse error hba rawline: host all all all scram-sha-256

Причина:

После завершения процесса сквозной аутентификации получена строка из pga_hba.conf, которая не валидна с точки зрения реализации метода разбора, заданного в PgBouncer.

Решение:

Заменить строку в pg_hba.conf на корректную.

Проблема:

WARNING A-0x2681490 (1): database/(nouser)@127.0.0.1:6667 auth server login failed

Причина:

Процесс аутентификации завершился с ошибкой. Данное сообщение возникает, если параметр log_connections установлен в значение 0.

Решение:

Аутентифицироваться с правильным паролем или именем пользователя.

Проблема:

WARNING: auth handshake timeout expired

Причина:

Превышено время обмена пакетами "рукопажатия" (время определяется значением параметра auth_handshake_timeout).

Решение:

Увеличить значение параметра auth_handshake_timeout, выяснить причину задержки с целью ее устранения.

Проблема:

WARNING: authentication timeout expired: user=username database=database, clientid=11

Причина:

Время обмена пакетами аутентификации пользователя превышает значение параметра authentication_timeout.

Решение:

Увеличить значение параметра authentication_timeout, выяснить причину задержки и устранить ее.

Проблема:

WARNING: AUTH: auth last token context is found for: username|database|hostname|nossl

Причина:

В списке токенов последней аутентификации клиентов не найден токен для данного пользователя.

Решение:

Выяснить причину отсутствия токена и устранить ее.

Для сбора диагностической информации:

установка параметра файла postgresql.conf log_min_messages в значение DEBUG5;
установка параметр файла pgbouncer.ini verbose в значение 2.

Собранную информацию необходимо передать в поддержку.

Проблема:

WARNING: AUTH: auth context is not found

Причина:

Переданный токен аутентификации не найден.

Решение:

Аналогично действиям для ошибки в примере выше, необходимо собрать диагностическую информацию и передать ее в поддержку.