postgrespro
ERROR: WAL segment ... could not be archived in 300 seconds при использовании pg_receivewal
При выполнении 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 с включенным сжатием
В режиме 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
Все с этим парятся. Я пока выхожу из положения, меняя 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 с этим кажется не ничего не может поделать.
Не, тут вся суть сводится к тому, что pg_probackup умеет читать из архива WAL несжатые файлы .partial, а вот когда включено сжатие на pg_receivewal, то тут наступает облом. А "облом", потому что gunzip (а точнее его либы) не умеют расшифровывать .gz.partial
Я от компресси самой утилитой с самого начала отказался. У меня бэкапы на ZFS, где включена компрессия.
Прочитать-то можем, но там проблема в том, что мы не можем однозначно отличить легально оборванный кусок пожатых данных от нелегально (коррапт). Сейчас мы такой кейс однозначно интерпретируем как коррапт и падаем с ошибкой. Мы можем это поведение сделать менее строгим и в некоторых случаях интерпретировать такой кондишн как легальный, но это не тривиально, быстрый "тяп-ляп" фикс уже не выходит.
А какой смысл это это делать? Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно). Было бы более логично обсуждать механизмы работы самого pg_receivewal - например не сжимать .partial до тех пор, пока весь сегмент не "приедет". А так, даже в документации pbk написано про archive_timeout. Возможно стоит немного дописать про необходимость настройки этого параметра для конкретно такого случая, с включенным сжатием в pg_receivewal.
Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно).
Так если постгрес обращается к архиву через probackup archive-get, то разжатие partial опять же становится нашей головной болью.
Даже если вы в pbk это сделаете, то в самом postgres-е процесс recovery все равно не сможет .gz.partial обработать без дополнительной обработки (в виде zcat + truncate, и то не факт что правильно).
Так если постгрес обращается к архиву через probackup archive-get, то разжатие partial опять же становится нашей головной болью.
Ну если постгрес пойдет в архив через archive-get, то логично ожидать, что этот архив пишется через archive_push? ) А там, если я все правильно понимаю, .partial не будет
Ну если постгрес пойдет в архив через archive-get, то логично ожидать, что этот архив пишется через archive_push? )
Нет, по умолчанию обращение к архиву идет через archive-get, пользователь может это поменять, конечно, но по умолчанию именно archive-get. А пополняться архив может и c помощью pg_receivewal, это вполне легальная комбинация.
Пользователь записал некое состояние в архив и ожидает, что при восстановлении из бэкапа может получить это же состояние. И мы обязаны давать гарантию, что его ожидания соответствуют действительности.
Пользователь записал некое состояние в архив и ожидает, что при восстановлении из бэкапа может получить это же состояние. И мы обязаны давать гарантию, что его ожидания соответствуют действительности.
Ну, повторюсь, мне кажется, что тут надо решать проблему в плоскости pg_receivewal. Ведь проблема по сути со сжатием/расжатием. Или другой алгоритм сжатия применять (что наверно нереально, из-за обратной совместимости), или, как вариант, дублировать несжатый .partial в tmpfs (чтобы не прогонять через диск весь объем WAL в случае SSD).
Решение на стороне pg_receivewal представляется сомнительным, ему сначала надо будет продраться через бесконечный bikeshedding в рассылке, после чего оно если и появится то только в новой версии.
Значит придется разрабатывать pg_receivewal-pro :) Еще как вариант - это отключить сжатие в pg_receivewal и, либо как beremour складывать на ФС со сжатием, либо натравить на каталог какую-нибудь конструкцию с inotify, которая будет следом сжимать полные сегменты.
Я только одно не понял - решение с zcat + truncate адекватно будет работать с .gz.partial или невозможно такое решение назвать надежным? Я клоню к тому, что решение pg_receivewal с включенным сжатием потенциально приводит к проблемам с неполным сегментом и проблема касается не сколько pbk, сколько вообще возможности восстановить субд с использованием .gz.partial-сегмента. Тут как минимум это нужно хотя бы как-то отразить в документации самого pg_receivewal
Значит придется разрабатывать pg_receivewal-pro :)
Зачем так сложно, просто допилим чтение сжатых partial файлов.
Уважаемые разработчики, а на каком сейчас этапе находится эта возможность ?
просто допилим чтение сжатых partial файлов.
Because the period for your host to generate a wal file exceeds the default of 300 seconds, you can increase the archive timeout during backup or adjust it to a smaller value, such as 200 seconds, in postgreSQL. conf.
