ERROR: WAL segment ... could not be archived in 300 seconds при использовании pg_receivewal

[alexandermalykhin]

При выполнении PAGE backup в режиме archive и низкой активности в БД процесс завершается с ошибкой:

2020-10-30 20:13:22 MSK [1056406]: INFO: Wait for LSN 864/966B8B40 in archived WAL segment /srv/storage/postgres_backup/wal/pgsrv/000000010000086400000096
2020-10-30 20:18:22 MSK [1056406]: ERROR: WAL segment 000000010000086400000096 could not be archived in 300 seconds
2020-10-30 20:18:22 MSK [1056406]: WARNING: Backup QJ0XYP is running, setting its status to ERROR

Бэкап снимается с реплики, на мастере параметр archive_timeout = off
Архив WAL ведется с помощью pg_receivewal с включенным сжатием

[alexandermalykhin]

В режиме VERBOSE последние сообщения:

VERBOSE: Skipping the unchanged file: "/srv/pg/replica/base/26216/121341507"
VERBOSE: Writing headers for file "base/28412/1716019" offset: 2499160, len: 214, crc: 1663486584
VERBOSE: File "/srv/pg/replica/base/28412/1716019". Copied 18039 bytes
VERBOSE: Skipping the unchanged file: "/srv/pg/replica/base/28412/1708513"
VERBOSE: Skipping the unchanged file: "/srv/pg/replica/base/237728173/260063695"
VERBOSE: Skipping the unchanged file: "/srv/pg/replica/base/28412/1708513.1"
INFO: Data files are transferred, time elapsed: 12m:28s
VERBOSE: (query) SET client_min_messages = warning;
VERBOSE: (query) SET datestyle = 'ISO, DMY';
VERBOSE: (query) SELECT pg_catalog.txid_snapshot_xmax(pg_catalog.txid_current_snapshot()), current_timestamp(0)::timestamptz, pg_catalog.pg_last_wal_replay_lsn(), labelfile, spcmapfile FROM pg_catalog.pg_stop_backup(false, false)
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
LOG: stop_lsn: 864/EB7342E8
LOG: Looking for LSN 864/EB7342E8 in segment: 0000000100000864000000EB
INFO: Wait for LSN 864/EB7342E8 in archived WAL segment /srv/storage/postgres_backup/wal/pgsrv/0000000100000864000000EB
ERROR: WAL segment 0000000100000864000000EB could not be archived in 10 seconds
WARNING: Backup QJ1807 is running, setting its status to ERROR

[beremour]

Все с этим парятся. Я пока выхожу из положения, меняя archive_timeout на мастер-базе перед началом бэкапа (колхоз конечно).

ssh master "psql -c 'ALTER SYSTEM SET archive_timeout="'"1min"'";' -c 'select pg_reload_conf();'"
pg_probackup-12 backup ...  --archive-timeout 62
ssh master "psql -c 'ALTER SYSTEM RESET archive_timeout;' -c 'select pg_reload_conf();'"

Помнится, это неприятная "фича" самого Postgres, pg_probackup с этим кажется не ничего не может поделать.

[alexandermalykhin]

Не, тут вся суть сводится к тому, что pg_probackup умеет читать из архива WAL несжатые файлы .partial,
а вот когда включено сжатие на pg_receivewal, то тут наступает облом.
А "облом", потому что gunzip (а точнее его либы) не умеют расшифровывать .gz.partial

[beremour]

Я от компресси самой утилитой с самого начала отказался. У меня бэкапы на ZFS, где включена компрессия.

[gsmolk]

Прочитать-то можем, но там проблема в том, что мы не можем однозначно отличить легально оборванный кусок пожатых данных от нелегально (коррапт). Сейчас мы такой кейс однозначно интерпретируем как коррапт и падаем с ошибкой. Мы можем это поведение сделать менее строгим и в некоторых случаях интерпретировать такой кондишн как легальный, но это не тривиально, быстрый "тяп-ляп" фикс уже не выходит.

[alexandermalykhin]

А какой смысл это это делать?
Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно).
Было бы более логично обсуждать механизмы работы самого pg_receivewal - например не сжимать .partial до тех пор, пока весь сегмент не "приедет".
А так, даже в документации pbk написано про archive_timeout. Возможно стоит немного дописать про необходимость настройки этого параметра для конкретно такого случая, с включенным сжатием в pg_receivewal.

[gsmolk]

Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно).

Так если постгрес обращается к архиву через probackup archive-get, то разжатие partial опять же становится нашей головной болью.

[alexandermalykhin]

Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно).

Так если постгрес обращается к архиву через probackup archive-get, то разжатие partial опять же становится нашей головной болью.

Ну если постгрес пойдет в архив через archive-get, то логично ожидать, что этот архив пишется через archive_push? )
А там, если я все правильно понимаю, .partial не будет

[gsmolk]

Ну если постгрес пойдет в архив через archive-get, то логично ожидать, что этот архив пишется через archive_push? )

Нет, по умолчанию обращение к архиву идет через archive-get, пользователь может это поменять, конечно, но по умолчанию именно archive-get. А пополняться архив может и c помощью pg_receivewal, это вполне легальная комбинация.

[gsmolk]

Пользователь записал некое состояние в архив и ожидает, что при восстановлении из бэкапа может получить это же состояние. И мы обязаны давать гарантию, что его ожидания соответствуют действительности.

[alexandermalykhin]

Пользователь записал некое состояние в архив и ожидает, что при восстановлении из бэкапа может получить это же состояние. И мы обязаны давать гарантию, что его ожидания соответствуют действительности.

Ну, повторюсь, мне кажется, что тут надо решать проблему в плоскости pg_receivewal.
Ведь проблема по сути со сжатием/расжатием. Или другой алгоритм сжатия применять (что наверно нереально, из-за обратной совместимости), или, как вариант, дублировать несжатый .partial в tmpfs (чтобы не прогонять через диск весь объем WAL в случае SSD).

[gsmolk]

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

[alexandermalykhin]

Значит придется разрабатывать pg_receivewal-pro :)
Еще как вариант - это отключить сжатие в pg_receivewal и, либо как beremour складывать на ФС со сжатием, либо натравить на каталог какую-нибудь конструкцию с inotify, которая будет следом сжимать полные сегменты.

Я только одно не понял - решение с zcat + truncate адекватно будет работать с .gz.partial или невозможно такое решение назвать надежным?
Я клоню к тому, что решение pg_receivewal с включенным сжатием потенциально приводит к проблемам с неполным сегментом и проблема касается не сколько pbk, сколько вообще возможности восстановить субд с использованием .gz.partial-сегмента.
Тут как минимум это нужно хотя бы как-то отразить в документации самого pg_receivewal

[gsmolk]

Значит придется разрабатывать pg_receivewal-pro :)

Зачем так сложно, просто допилим чтение сжатых partial файлов.