ConsDB

WAL sender

время чтения ~2 мин.

WAL Sender — отправляет WAL-записи с основного (primary) сервера на реплику (standby) в режиме потоковой (streaming) репликации

Ключевой компонент физической репликации и обеспечивает почти мгновенную синхронизацию данных между серверами

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

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

  1. Replica (standby) устанавливает репликационное подключение к primary (обычно через отдельный порт или специального пользователя с правом REPLICATION).
  2. Postmaster на primary запускает процесс WAL Sender для этого подключения.
  3. WAL Sender:
    • Читает новые WAL-записи из:
      • wal_buffers (в shared memory) — если они ещё не сброшены на диск,
      • или из файлов в pg_wal/ — если уже записаны.
    • Упаковывает их в протокол репликации PostgreSQL.
    • Отправляет по TCP-соединению на WAL Receiver на standby.
  4. ==Standby получает WAL через процесс WAL Receiver(Stats collector), пишет в свой pg_wal/ и применяет изменения (в режиме restore).=
  • Это отдельный ОС-процесс, запускаемый postmaster по требованию (при подключении реплики).
  • В ps aux на primary вы увидите
postgres: wal sender process user_name [IP] streaming 0/1A2B3C4D
  • На standby работает симметричный процесс:
postgres: wal receiver
РежимПоведение WAL Sender
Async (асинхронный)Отправляет WAL и не ждёт подтверждения от реплики. Максимальная производительность, но возможна потеря данных при падении primary.
Sync (синхронный)Ждёт, пока реплика запишет WAL на диск (synchronous_standby_names), прежде чем подтвердить COMMIT клиенту. Гарантирует zero data loss, но снижает скорость записи.

Что показывает WAL Sender?

  • Текущий отправленный LSN,
  • Состояние подключения (streaming, catchup, stopping),
  • Имя слота репликации (Replication slot) (если используется),
  • IP и пользователя реплики.
SELECT * FROM pg_stat_replication;

Replication slot — это механизм в PostgreSQL, который гарантирует, что WAL-файлы, необходимые для реплики (или логической подписки), не будут удалены с primary-сервера раньше времени, даже если реплика временно отключена.

Без replication slot’ов PostgreSQL автоматически удаляет старые WAL-файлы, когда они больше не нужны для:

  • recovery (после checkpoint’а),
  • архивации,
  • или текущих реплик.

Проблема

Если реплика упадёт или отстанет надолго — нужные ей WAL-файлы могут быть удалены. При попытке подключиться она получит ошибку вида: requested WAL segment ... has already been removed

И реплику придётся пересоздавать с нуля (base backup + новый старт).

Важные нюансы

  • Один WAL Sender = одна реплика (или один логический декодер).

  • Если реплика отключается, WAL Sender завершается.

  • При использовании replication slot WAL Sender не позволяет удалять WAL, даже если реплика надолго отключена → может заполнить диск!

  • WAL Sender не шифрует данные — для защиты нужен SSL (настраивается в pg_hba.conf).

Вид графа

Обратные ссылки