Креш при попытке выполнить полный бэкап

[ykurenkov]

CentOS7, PostgreSQL 11.8, pg_probackup 2.4.2

INFO: Progress: (11035/11360). Process file "base/8511489/8519451"
pg_probackup: could not receive data from WAL stream: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
ERROR: Problem in receivexlog
ERROR: interrupted during backup
ERROR: Data files transferring failed, time elapsed: 48m:39s
WARNING: backup in progress, stop backup
WARNING: Backup QGEM4Z is running, setting its status to ERROR

При этом в postgresql.log только

2020-09-10 00:20:25 +05 [unknown] postgres@[local] PID:40447 LOG:  terminating walsender process due to replication timeout
2020-09-10 00:20:29 +05 postgres postgres@[local] PID:40407 LOG:  could not send data to client: Broken pipe
2020-09-10 00:20:29 +05 postgres postgres@[local] PID:40407 FATAL:  connection to client lost

Конфигурация pg_probackup

# Backup instance information
pgdata = /var/lib/pgsql/11/data
system-identifier = 6866009253976847796
xlog-seg-size = 16777216
# Connection parameters
pgdatabase = postgres
pgport = 5432
# Replica parameters
replica-timeout = 10min
# Archive parameters
archive-timeout = 10min
# Logging parameters
log-level-console = INFO
log-level-file = INFO
log-filename = pg_probackup-ngp-%a.log
log-rotation-age = 1d
# Retention parameters
retention-redundancy = 2
retention-window = 7

[gsmolk]

Добрый день.
Не было ли каких-то сетевых проблем в этот момент времени?

[ykurenkov]

Затрудняюсь сказать, но архивация wal в это время работает.

[gsmolk]

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

2020-09-10 00:20:29 +05 postgres postgres@[local] PID:40407 LOG:  could not send data to client: Broken pipe
2020-09-10 00:20:29 +05 postgres postgres@[local] PID:40407 FATAL:  connection to client lost

Здесь видно, что бэкенд не смог отправить результаты выполнения запроса клиенту.

[ykurenkov]

Но это был локальный бэкап. Бэкап в пределах хоста на СХД, подключенное по NFS.

[ykurenkov]

Архивация WAL работает нормально (при удалении сбойных архивов удалились и более ранние WALы)

ARCHIVE INSTANCE 'ngp'
================================================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno                 Max Segno                 N segments  Size   Zratio  N backups  Status
================================================================================================================================

1    0           0/0          0000000100000132000000B4  0000000100000132000000BA  7           112MB  1.00    1          OK

На сети вроде спокойно. Ещё раз запустил полный бэкап. Жду....

[gsmolk]

Можете выполнить запрос ниже?

show wal_sender_timeout;

[ykurenkov]

postgres=# show wal_sender_timeout;
 wal_sender_timeout
--------------------
 1min
(1 row)

[gsmolk]

Как временное решение, я бы предложил увеличить этот параметр до, скажем, 10 минут.

[ykurenkov]

postgres=# show wal_sender_timeout;
 wal_sender_timeout
--------------------
 10min
(1 row)

10 дней буду без компа - будет время для проверки и сбора статистики.

[gsmolk]

Мы со своей клиентской стороны по идее можем этот параметр переопределять при подключении.
Надо изучить этот вопрос.

[ykurenkov]

Еще раз обращу внимание: это был локальный бэкап, не удаленный.

[gsmolk]

Еще раз обращу внимание: это был локальный бэкап, не удаленный.

Я понял. У меня есть одна догадка о причинах происходящего, но её нужно проверить.

[gsmolk]

Сервер PostgreSQL, а конкретно wal_sender, который обслуживает клиента, периодически отсылает keepalive сообщения. Если от клиента не поступал ответ в течении времени, превыщающем wal_sender_timeout, то коннект терминируется.
Если pg_probackup запускается локально, то клиент(pg_probackup) может не отвечать, например, в результате высокой нагрузки на машине, т.е. клиент просто не успел получить свой cpu time slice.

[ykurenkov]

Что делать в подобных случаях? Каковы методы предотвращения появления их?

[gsmolk]

Как временное решение - задать значение параметр wal_sender_timeout побольше.
Я надеюсь, что мы в ближайшее время возьмемся за перепил нашего libpq интерфейса, и тогда сможем сами при открытии коннекта задавать этот параметр, не дергая юзера.

[gsmolk]

Будет исправлено в рамках #350