В PostgreSQL процесс получения журналов walreceiver запускается на реплике только после того, как процесс startup применит все накопившиеся WAL. Это не создаёт особых проблем, если процесс startup успевает накатывать полученные журналы. Проблема проявляется, если используется реплика с отложенным применением журнальных записей, например, на сутки. Реплика не будет получать журналы сутки, слот репликации будет их удерживать на мастере.
Если процесс walreceiver остановится, то он не запустится до тех пор, пока не пройдёт время задержки, установленное параметром recovery_min_apply_delay. Команд ручного запуска процесса walreceiver нет. Получится, что сутки мастер копит журналы, только потом запускается walreceiver и начинает вытягивать журнальные файлы. Такое поведение нелогично, но его задокументировали: "When the standby is started and primary_conninfo is set correctly, the standby will connect to the primary after replaying all WAL files available in the archive. If the connection is established successfully, you will see a walreceiver in the standby, and a corresponding walsender process in the primary."
Всё время, до запуска walreceiver, слот репликации на мастере удерживает файлы журналов. На мастере скопится много журналов и, если не хватит места, то экземпляр мастера подвиснет по нехватке места в директории pg_wal (или слот инвалидируется по параметру max_slot_wal_keep_size и реплику придётся пересоздать).
Что приводит к остановке walreceiver? Это не только перезапуск экземпляра реплики. Достаточно разрыва сокета между wareceiver и walsender из-за сетевых проблем, перезапуск walsender, перезапуск экземпляра мастера.
То, что walreceiver долго не стартует, не даёт использовать реплики с отложенным применением журналов, как аналог постоянно обновляемых (in place) бэкапов. Утилита pg_combinebackup не может применять инкрементальные бэкапы in-place (утилита копирует полный бэкап, сливая его с инкрементальными, в новую директорию), поэтому использование реплик с отложенным применением журналов имеет преимущества по сравнению с инкрементальными бэкапами.
Реплику с отложенным применением WAL можно было бы использовать для случаев, когда на мастере возникнет повреждение. При появлении повреждения, можно приостановить применение журналов, сделать бэкап реплики и экспериментировать с репликой (или с бэкапом), докатывая журналы до момента сбоя. Если момент сбоя будет определён неверно, и применятся лишние журналы (позже точки повреждения), то откатить их нельзя, для такого случая и понадобится сделанный вначале бэкап с реплики (или реплика, если экспериментировали с бэкапом), чтобы повторить всё заново.
История проблемы
Впервые, на проблему обратил внимание Константин Книжник в 2019 году. Альваро Эррера подтвердил, что он тоже столкнулся с этой проблемой. Томас Манро, как менеджер коммитфеста, запросил патч с тестом, чтобы патч прошел проверку коммитфест бота. Коммитер Майкл Пакье счёл логику патча убогой (kind of ugly) и предложил ввести параметр конфигурации, чтобы DBA могли выбирать, когда им нужно запускать walreceiver. Константин добавил параметр. За приятной перепиской пролетел год.
Проблема не отпускала пользователей PostgreSQL. Следующим, столкнувшимся с проблемой, и решившимся написать в pg-hackers, был Асим Правен. Он независимо от Константина создал патч и качественно описал как и когда проявляется проблема. Например, указал, что журнальные записи создаются большим числом серверных процессов, а применяет записи один процесс - startup и, при реальных нагрузках, отставание реплики от мастера будет обычным делом. Также указал, что при реальной работе, с использованием синхронного коммита, поведение synchronous_commit в значении remote_write и on становится эквивалентным remote_apply до тех пор, пока startup не применит накопившиеся журналы и не запустит walreceiver. Такое поведение делает использование синхронной фиксации транзакций опасной для мастера.
Майкл Пакье отметил, что Асим Правен ввёл третий вариант запуска walreceiver: немедленный (startup), помимо consistency и проблемного (exhaust) и дал ценные замечания по логике поиска журнала, который нужно запрашивать.
Также, Асим создал два теста, проявляющие проблему: walreceiver останавливается из-за разрыва соединения и экземпляр реплики перезапускается. Для демонстрации задержки в применении журнальных записей, Асим, использовал параметр recovery_min_apply_delay. Асим отметил, что задержка применения может накапливаться естественным образом, даже если параметр recovery_min_apply_delay не установлен, поскольку генерация WAL на мастере происходит параллельно, а воспроизведение WAL на реплике выполняется только одним процессом startup.
Асим создал улучшенную логику сканирования файлов журнала реплики для определения того, какой журнал запрашивать у процесса walsender.
Асим написал гораздо более быстрое и менее инвазивное решение для определения начальной точки, с которой walreceiver должен начать запрашивать журналы у процесса walsender. Алгоритм следующий: сканируется первый блок каждого WAL-файла среди уже имеющихся на реплике, начиная с того WAL-файла, который, читается процессом startup для наката журнальной записи. Если первый блок WAL-файла валидный, процесс walreceiver переходит к следующему WAL-файлу проверяет его первый блок. Продолжает сканировать по одному WAL-файлу за раз, пока файлы не закончатся или блок будет невалидным. Начальной точкой будет являться начало предыдущего отсканированного WAL-файла. Преимущество алгоритма Асима в том, что не нужно читать все журнальные записи во всех WAL-файла до конца каждого файла, как это делалось в патче Константина. Более того, нет проблемы с частично полученным WAL-файлом: последняя полученная до сбоя walreceiver журнальная запись может не сохраниться на диске и это не будет проблемой - при повторном запуске walreceiver читает только первую запись в каждом журнальном файле и перезапросит весь файл. Слот репликации удерживает журналы целыми файлами и проблем с перезапросом WAL-файла, записи которого передавались ранее, не будет.
Патчем восхитились, пообсуждали и улучшили. В августе 2020 года Масахико Савада нашел ошибку. В ноябре 2021 года Борат Рупиредди дал много полезных комментариев по коду патча. За патч взялся Сумьядип Чакраборти и обновил его с учетом давних замечаний Майкла Пакье. Борат нашел в обновленном патче утечку памяти. Казалось бы патч можно коммитить, но...
Киотаро Хоригучи (NTT) попробовал патч и нашел, что патч не работал в простейшем случае. На этом обсуждение патча закончили.
Через 4 года
Через 4 года, в 2025 году у Сунил С. (Broadcom) появилось время, и он взялся за доработку патча. Как выяснил Сунил, Киотаро Хоригучи натолкнулся на проблему, которую породило исправление, внесенное в код PostgreSQL для устранения race condition между архиватором и checkpointer. Репутация патча была восстановлена.
Патч сменил 10 версий и был номинирован на коммитфест 19 версии в конце 2025 года со статусом Ready for Committer, но не нашёл коммитера. Что неудивительно, так как в коде патча присутствует слово "FIXME".
Третий пост о проблеме появился в апреле 2026 года с заголовком: "баг это или фича реквест??" где справедливо отмечен отложенный сюрприз, который таит нерешенная проблема: первоначальная настройка репликации работает идеально, усыпляя бдительность администратора, а спустя недели/месяцы, как только произойдет перезагрузка экземпляра реплики, репликация незаметно нарушается. Было отмечено, что в PostgreSQL не существует способа вручную запустить walreceiver и предложено хотя бы дать такую возможность.
Воспроизведение проблемы
Запустим нагрузку:
pgbench -i
pgbench -T 6000 -R 700 -P 10Создадим реплику с отложенным применением журналов:
export PGDATA=/var/lib/postgresql/tantor-se-18-replica/data1
pg_ctl stop -D /var/lib/postgresql/tantor-se-18-replica/data1
rm -rf /var/lib/postgresql/tantor-se-18-replica/data1
psql -qc "select pg_drop_replication_slot('replica1')"
pg_basebackup -D $PGDATA -P -R -C --slot=replica1 -c fast
echo "port=5433" >> $PGDATA/postgresql.auto.conf
echo "cluster_name='replica1'" >> $PGDATA/postgresql.auto.conf
echo "logging_collector = off" >> $PGDATA/postgresql.auto.conf
echo "recovery_min_apply_delay = '5min'" >> $PGDATA/postgresql.auto.conf
pg_ctl start -D $PGDATA
waiting for server to start....
done
server startedРепликация идёт, walreceiver работает, журналы применяются через 5 минут.
psql -p 5433 -qc "select pg_get_wal_replay_pause_state() state, pg_is_wal_replay_paused() p, pg_last_wal_replay_lsn() replay_lsn, pg_last_wal_receive_lsn() receive_lsn, pg_last_xact_replay_timestamp();"
psql -qc "select application_name, state, flush_lsn, replay_lsn, replay_lag from pg_stat_replication"
state | p | replay_lsn | receive_lsn | pg_last_xact_replay_timestamp
-----------+---+------------+-------------+-------------------------------
not paused | f | 0/4000130 | 0/671A360 | 21:25:19.866532+03
(1 row)
application_name | state | flush_lsn | replay_lsn | replay_lag
-----------------+-----------+-----------+------------+-----------------
replica1 | streaming | 0/671B3D0 | 0/4000130 | 00:01:30.018386
(1 row)Даже бэкап с реплики выполняется:
rm -rf /var/lib/postgresql/tantor-se-18-replica/data2
pg_basebackup -p 5433 -D /var/lib/postgresql/tantor-se-18-replica/data2 -P -R -c fast
40190/40190 kB (100%), 1/1 tablespaceПерезапустим экземпляр мастера или реплики:
pg_ctl restart -D /var/lib/postgresql/tantor-se-18-replica/data1
psql -qc "select application_name, state, flush_lsn, replay_lsn, replay_lag from pg_stat_replication"
psql -p 5433 -qc "select pg_get_wal_replay_pause_state() state, pg_is_wal_replay_paused() p,
pg_last_wal_replay_lsn() replay_lsn, pg_last_wal_receive_lsn() receive_lsn, pg_last_xact_replay_timestamp();"
waiting for server to shut down....
server stopped
waiting for server to start....
LOG: entering standby mode
LOG: redo starts at 0/3000080
LOG: consistent recovery state reached at 0/4000130
LOG: database system is ready to accept read-only connections
done
server started
application_name | state | flush_lsn | replay_lsn | replay_lag
-----------------+-------+-----------+------------+------------
(0 rows)
state | p | replay_lsn | receive_lsn | pg_last_xact_replay_timestamp
-----------+---+------------+-------------+-------------------------------
not paused | f | 0/4000130 | | 21:25:19.866532+03
(1 row)walreceiver не запустился. Он запустится только через recovery_min_apply_delay. А этот параметр может быть выставлен в несколько суток. Просто так поменять его нельзя, так как применятся изменения, и реплику не удастся использовать для восстановления на момент в прошлом.
Решение проблемы задержки с запуском walreceiver
В Tantor Postgres, начиная с версии 17.9, добавлен параметр wal_receiver_start_at, который устраняет проблему: walreceiver можно запускать сразу после запуска экземпляра или по достижению согласованного состояния. Параметр был добавлен техподдержкой Тантор, по запросу администратора небольшой компании, купившей Tantor Postgres SE 1C.
В PostgreSQL новые параметры добавлются только в мажорные версии, которые выпускаются раз в год, в минорные не добавляются. Это сделано потому, что новшества добавляются членами сообщества независимо друг от друга и могут повлиять на параллельно добавляемые новшества, что породит ошибки, похожие на ту, которую обнаружил Киотаро Хоригучи (NTT): Два патча работали независимо друг от друга без ошибок, но при применении первого патча нужно было учесть его исправления и доработать второй патч.
В Tantor Postgres новые возможности добавляются быстрее - в минорных версиях, так как разработка централизована и есть возможность оценить влияние изменений друг на друга. В примере на картинке параметры enable_eager_aggregate и min_eager_agg_group_size появятся в 19 версии PostgreSQL, а в Tantor Postgres начиная с версии 18.3.
Запрос на добавление параметра wal_receiver_start_at был создан 24 июля 2025 года. На следующий день техподдержка создала задачу на добавление параметра. Седьмую версию патча Сунил опубликовал через 4 дня, 29 июля. Патч стал активно дорабатываться. Десятая версия патча была выпущена 23 ноября, после неё доработок не было. 7 января 2026 года патч получил статус ready for commiter и разработчики Тантор добавили параметр в ближайшие версии Tantor Postgres 17 и 18 версий. Первой, в которой появился параметр, была сборка Tantor Postggres BE 18.1, которая вышла 16 марта 2026 года.
Установим параметр wal_receiver_start_at на реплике и перезапустим экземпляр:
psql -p 5433 -qc "alter system set wal_receiver_start_at=startup"
pg_ctl restart -D $HOME/tantor-se-18-replica/data1
psql -p 5433 -qc "select pg_get_wal_replay_pause_state() state, pg_is_wal_replay_paused() p,
pg_last_wal_replay_lsn() replay_lsn, pg_last_wal_receive_lsn() receive_lsn, pg_last_xact_replay_timestamp();"
psql -qc "select application_name, state, flush_lsn, replay_lsn, replay_lag from pg_stat_replication"
ALTER SYSTEM
LOG: received fast shutdown request
waiting for server to shut down....
done
server stopped
waiting for server to start....
LOG: database system was shut down in recovery at 21:31:49 MSK
LOG: requesting stream from beginning of: "000000010000000000000009"
LOG: entering standby mode
LOG: redo starts at 0/3000080
LOG: started streaming WAL from primary at 0/9000000 on timeline 1
LOG: consistent recovery state reached at 0/66C92B8
LOG: database system is ready to accept read-only connections
done
server started
state | p | replay_lsn | receive_lsn | pg_last_xact_replay_timestamp
-----------+---+------------+-------------+-------------------------------
not paused | f | 0/66FE800 | 0/C899BE8 | 21:26:50.104791+03
(1 row)
21:31:50.113 MSK [92940] LOG: autoprewarm successfully prewarmed 2550 of 2550 previously-loaded blocks
application_name | state | flush_lsn | replay_lsn | replay_lag
-----------------+-----------+-----------+------------+-----------------
replica1 | streaming | 0/C89A6E8 | 0/66FFC18 | 00:00:00.574187
(1 row)Процесс walreceiver запустился сразу после запуска экземпляра реплики.
Защита мастера от повреждений репликой с отложенным применением журналов
Реплика с отложенным на долгое время (сутки или несколько суток) применением журналов полезна тем, что если на мастере возникнет повреждение, то можно будет приостановить применение журналов, сделать бэкап этой реплики и экспериментировать с бэкапом, докатывая журналы до момента сбоя. При этом будет иметься бэкап (он же реплика), с которого ещё раз можно будет взять бэкап, если не угадать со временем восстановления. Нужно только помнить, что после рестарта реплики, нужно снова ставить применение журналов на паузу. Также следить за тем, чтобы журналы удерживались или скопировать их.
psql -p 5433 -qc "select pg_wal_replay_pause()"
rm -rf /var/lib/postgresql/tantor-se-18-replica/data2
pg_basebackup -p 5433 -D /var/lib/postgresql/tantor-se-18-replica/data2 -P -R -c fast
LOG: recovery has paused
HINT: Execute pg_wal_replay_resume() to continue.
pg_wal_replay_pause
---------------------
(1 row)
54422/54422 kB (100%), 1/1 tablespaceПримеры повреждений мастера: удаление базы данных или важных объектов по ошибке. Вместо реплики с отложенным применением можно использовать бэкапы. Они могут быть хорошим решением, если размер кластера небольшой. В 17 версии появились инкрементальные бэкапы, но есть недостаток: их нельзя накладывать на директорию с полным бэкапом (in-place).
Заключение
Параметр wal_receiver_start_at позволяет запускать walreceiver на реплике сразу или по достижению согласованного состояния файлов. При перезапуске экземпляра реплики или процесса walreceiver, процесс walreceiver будет немедленно запускаться и продолжать вытягивать журналы без задержки.
Это позволяет использовать реплику с отложенным применением журналов для защиты мастера от повреждений, как постоянно обновляемый (in place) бэкап. С реплики с отложенным применением журналов можно делать бэкапы.
Без параметра wal_receiver_start_at, реплика не может принимать журнальные файлы до истечения recovery_min_apply_delay.