Startup process - WAL receiver (standby)

psql PostgreSQL

Startup process

Startup process — это специальный процесс в PostgreSQL, который запускается только на standby-сервере (или при восстановлении из бэкапа) и отвечает за применение WAL-записей к данным, чтобы привести кластер в согласованное и актуальное состояние.

ядро механизма восстановления (recovery) и работает только в режиме “реплика” или “восстановление”, но никогда на основном (primary) сервере.

Читать WAL-записи (из файлов pg_wal/ или из архива) и применять их к локальным данным (таблицам, индексам), чтобы восстановить состояние базы на определённый момент времени или синхронизироваться с primary.

Этот процесс делает реплику актуальной и позволяет ей работать в режиме Hot Standby (чтение на реплике).

Когда запускается Startup process?

1. При старте standby-сервера, если в каталоге данных есть:
   • standby.signal (в PostgreSQL ≥12), или
   • recovery.conf (в PostgreSQL ≤11).
2. При восстановлении из бэкапа (Point-in-Time Recovery (PITR)), если указан recovery_target_*. Это управляемое восстановление до заданной точки во времени (PITR — Point-In-Time Recovery), обычно выполняемое вручную администратором.

Что именно делает Startup process?

1. Инициализация режима восстановления

• Читает параметры из postgresql.auto.conf / standby.signal:
  • primary_conninfo — откуда брать WAL,
  • restore_command — как получать WAL из архива,
  • recovery_target_* — до какой точки восстанавливать.

2. Запуск WAL Receiver (если настроена streaming replication)

• Если указан primary_conninfo, он порождает процесс wal receiver, который будет получать WAL напрямую с primary.

3. Чтение и применение WAL

• Startup process последовательно читает WAL-файлы из:
  • pg_wal/ (если они есть локально),
  • или вызывает restore_command для получения из архива,
  • или получает через WAL Receiver (streaming).
• Для каждой WAL-записи он выполняет REDO-операцию:
  • Обновляет страницы в shared_buffers,
  • Применяет изменения к таблицам, индексам, системным каталогам,
  • Обновляет CLOG, visibility map и другие служебные структуры.

4. Управление видимостью для Hot Standby

• Пока идёт восстановление, backend-процессы могут обслуживать SELECT (Hot Standby).
• Startup process предоставляет специальный snapshot, который позволяет читателям видеть только зафиксированные и применённые данные.
• Он отслеживает, какие XID уже видимы, чтобы не нарушить MVCC.

5. Остановка восстановления (если задан recovery target | Point-In-Time Recovery)

• Если достигнута цель (recovery_target_time, recovery_target_xid и т.д.):
  • Startup process останавливает применение WAL,
  • Создаёт файл recovery.done (или удаляет standby.signal),
  • Переводит сервер в режим primary (если не указано иное).

6. Подготовка к переходу в primary (при failover)

• При pg_ctl promote:
  • Startup process завершает восстановление,
  • Очищает состояние recovery,
  • Переключает кластер в режим записи.

Важные особенности

• Startup process — единственный процесс, который может модифицировать данные на standby.
• Все остальные backend’ы на standby только читают.
• Он не обрабатывает клиентские запросы — только применяет WAL.
• При остановке (например, при promote) он гарантирует согласованность: все применённые WAL — в данных, неприменённые — игнорируются.
• Если WAL повреждён или отсутствует — останавливает восстановление с ошибкой.

---

На standby можно проверить прогресс через:

SELECT * FROM pg_stat_wal_receiver;  -- если streaming
SELECT pg_last_wal_replay_lsn();     -- до какого LSN применено
SELECT pg_is_in_recovery();          -- true, если Startup ещё работает

WAL receiver ^psql-WAL-receiver

Только для физической репликации

WAL Receiver — это фоновый процесс на standby-сервере (реплике) в PostgreSQL, который принимает WAL-записи от WAL Sender с primary-сервера и записывает их в локальный каталог pg_wal/, чтобы standby мог применить изменения и оставаться синхронизированным.

Он является зеркальной парой WAL Sender’а и ключевым компонентом потоковой (streaming) физической репликации.

Главная задача WAL Receiver

Получать поток WAL-записей по сети от primary и сохранять их на диске standby-сервера, чтобы процесс восстановления (recovery) мог их применить.

• Поддерживать актуальную копию данных,
• Работать в режиме Hot Standby (чтение на реплике),
• Быстро заменить primary при отказе (failover).

Как работает WAL Receiver (по шагам)

1. Standby-сервер запускается в режиме восстановления (наличие standby.signal или recovery.conf).
2. Он устанавливает репликационное подключение к primary (указанному в primary_conninfo).
3. На standby запускается процесс WAL Receiver.
4. WAL Receiver:
   • Принимает WAL-записи по TCP от WAL Sender на primary,
   • Пишет их в локальный каталог pg_wal/ (точно такие же файлы, как на primary),
   • Обновляет метаданные: до какого LSN данные получены и записаны.
5. Процесс Startup (на standby) читает эти WAL-файлы и применяет изменения к локальным данным (heap, индексы и т.д.).

WAL Receiver не применяет данные сам — он только принимает и сохраняет WAL.
Применение делает Startup process.

На standby можно проверить состояние через:

SELECT * FROM pg_stat_wal_receiver;

---

• WAL Receiver не работает без Startup process — а тот запускается только в режиме recovery.
• При потере связи с primary WAL Receiver:
  • Повторяет попытки подключения (если настроено),
  • Standby переходит в режим archive recovery (если настроен restore_command),
  • Или останавливается (если архив недоступен).
• WAL Receiver не шифрует трафик — для безопасности нужен SSL в primary_conninfo.
• При использовании replication slot WAL Receiver сообщает primary, до какого LSN он получил данные, чтобы тот не удалял нужные WAL-файлы.