Target LSN *** could not be streamed in 1320 seconds

[sxnazirov]

Добрый день.
По крону "снимаю" бекап (Бэкап снимаете с реплики)

/opt/pgpro/std-16/bin/pg_probackup backup --instance=prod_db -j 80 --progress -b FULL --compress --delete-expired --stream --backup-path=/backup_path

все отрабатывает, но иногда (не знаю зависимости ) завершается ошибкой
prod_db 16 SCRRG2 2024-05-01 08:54:05+05 FULL STREAM 1/0 8h:54m 9130GB 0 zlib 1.54 2F2D/3905DD40 0/0 ERROR
в логе

INFO: Progress: (336212/336303). Process file "base/183593690/319508597"
INFO: Progress: (336213/336303). Process file "base/183593690/318930792"
INFO: Progress: Backup file "global/pg_control"
INFO: Data files are transferred, time elapsed: 8h:30m
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
INFO: Wait for LSN 2FA0/E5FFFB70 to be streamed
ERROR: Target LSN 2FA0/E5FFFB70 could not be streamed in 1320 seconds
ERROR: WAL streaming failed
WARNING: Backup SCRRG2 is running, setting its status to ERROR

OS: Rocky Linux 8.9 (Green Obsidian)
Kernel: Linux 4.18.0-513.11.1.el8_9.x86_64
Architecture: x86-64

select version();
version

PostgreSQL 16.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit

/opt/pgpro/std-16/bin/pg_probackup version
pg_probackup 2.7.3 community (Postgres Pro 16.2.2 standard) (compressions: zlib, pglz, lz4, zstd)

[funny-falcon]

Я хотел написать, что на мастере нагрузки в эти полчаса не было, потому сегмент на слейве всё ни как не мог закрыться... Это возможно?
Время перед 9 часами утра, может у вас в это время ни чего не происходит?

Но вообще, я подзабыл, как stream ведёт себя в такой ситуации. Попробую поиграться, чтобы увереннее дискуссию вести.

[xinferum]

Здравствуйте.

Поскольку вы снимаете бекап с реплики, возможна ситуация что у вас долгое время не было никакой активности на мастере и в wal логи ничего не попадало. Мы столкнулись с подобной проблемой.

Во-первых у вас в конфигурационном файле pg_probackup надо прописать параметр archive-timeout (https://postgrespro.ru/docs/postgrespro/16/app-pgprobackup), по умолчанию он равен 5 минутам. Например у нас он такой:

# Archive parameters
archive-timeout = 60min

И этот параметр должен быть больше чем параметр archive_timeout в вашем PostgreSQL. Этот параметр задает таймаут в рамках которого pg_probackup будет ждать нужный wal.

Во-вторых в самом PostgreSQL должен быть прописан archive_timeout (https://postgrespro.ru/docs/postgresql/16/runtime-config-wal#GUC-ARCHIVE-TIMEOUT), который должен быть меньше чем archive-timeout в pg_probackup. Это таймаут по истечение которого PostgreSQL будет переключаться на новый wal.
Однако мы у себя выяснили что PostgreSQL по этому таймауту не будет переключаться на новый wal если не было записано в wal хотя бы одной транзакции, то есть не было никакой активности во время очередного archive_timeout, так как текущий wal файл у него пустой. Вероятно вы сталкиваетесь с той же ситуацией.

Мы у себя в кластере PostgreSQL настроили в pg_cron задание которое раз в минуту создает минимальную транзакционную активность - записывает и удаляет одну и ту же строку в специальной таблице. Благодаря этому по archive_timeout в PostgreSQL у нас всегда происходит переключение на новый wal и в рамках archive-timeout в pg_probackup бекап на реплике получает нужный wal и бекап выполняется успешно.

[sxnazirov]

Здравствуйте.

Поскольку вы снимаете бекап с реплики, возможна ситуация что у вас долгое время не было никакой активности на мастере и в wal логи ничего не попадало. Мы столкнулись с подобной проблемой.

Во-первых у вас в конфигурационном файле pg_probackup надо прописать параметр archive-timeout (https://postgrespro.ru/docs/postgrespro/16/app-pgprobackup), по умолчанию он равен 5 минутам. Например у нас он такой:

# Archive parameters
archive-timeout = 60min

И этот параметр должен быть больше чем параметр archive_timeout в вашем PostgreSQL. Этот параметр задает таймаут в рамках которого pg_probackup будет ждать нужный wal.

Во-вторых в самом PostgreSQL должен быть прописан archive_timeout (https://postgrespro.ru/docs/postgresql/16/runtime-config-wal#GUC-ARCHIVE-TIMEOUT), который должен быть меньше чем archive-timeout в pg_probackup. Это таймаут по истечение которого PostgreSQL будет переключаться на новый wal. Однако мы у себя выяснили что PostgreSQL по этому таймауту не будет переключаться на новый wal если не было записано в wal хотя бы одной транзакции, то есть не было никакой активности во время очередного archive_timeout, так как текущий wal файл у него пустой. Вероятно вы сталкиваетесь с той же ситуацией.

Мы у себя в кластере PostgreSQL настроили в pg_cron задание которое раз в минуту создает минимальную транзакционную активность - записывает и удаляет одну и ту же строку в специальной таблице. Благодаря этому по archive_timeout в PostgreSQL у нас всегда происходит переключение на новый wal и в рамках archive-timeout в pg_probackup бекап на реплике получает нужный wal и бекап выполняется успешно.

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