Как устроены механизмы WAL Archiving и потоковой репликации в PostgreSQL? Что произойдёт с основным сервером, если реплика отключится, параметр wal_keep_size настроен некорректно или заполнится диск для хранения архивных логов?

Архивирование сохраняет WAL-сегменты, а streaming replication передаёт WAL реплике. Отключённая реплика может отстать; удержание WAL и сбой архивации способны заполнить диск primary.

wal_keep_size задаёт минимум сохраняемого WAL, но не гарантирует, что его хватит при длительном простое. Если нужные сегменты уже удалены и отсутствуют в архиве, реплику придётся восстанавливать. Replication slot может удерживать WAL и увеличивать его объём; необходимо контролировать лимиты и отставание. Ошибка записи в архив приводит к повторным попыткам архивации и накоплению WAL на primary. Исчерпание локального диска угрожает работе основного сервера. Нужны мониторинг свободного места, состояния архиватора и lag, а не ручное удаление pg_wal.

Источник: www.postgresql.org.