Почему WAL растёт при hot_standby_feedback и max_standby_streaming_delay

Администраторы PostgreSQL часто сталкиваются с неожиданным ростом объёма WAL (Write-Ahead Log) после изменения параметров репликации. В частности, комбинация hot_standby_feedback = on и max_standby_streaming_delay = 5h способна существенно увеличить количество генерируемых сегментов WAL даже при неизменной DML-нагрузке. Разберём механизмы этого влияния и предложим пути оптимизации.

Как работает hot_standby_feedback

Параметр hot_standby_feedback (включён) заставляет реплику отправлять мастеру информацию о текущих активных запросах. Мастер, получив эти данные, откладывает очистку (VACUUM) строк, которые могут понадобиться запросам на реплике. Это предотвращает конфликты репликации и ошибки вида query canceled due to conflict with recovery.

Однако плата за это - разрастание мёртвых кортежей на мастере. Чем дольше выполняются аналитические запросы на реплике, тем дольше мастер не может удалять старые версии строк. В результате VACUUM вынужден пропускать очистку, и мёртвые кортежи накапливаются. Каждое обновление (UPDATE) или удаление (DELETE) на мастере порождает новые версии строк, и все они фиксируются в WAL, увеличивая его объём.

Роль max_standby_streaming_delay

Параметр max_standby_streaming_delay = 5h задаёт максимальное время, в течение которого реплика может откладывать применение конфликтующих изменений из WAL. При hot_standby_feedback = on этот таймер редко срабатывает, так как мастер старается избегать конфликтов. Но если на реплике выполняются очень долгие запросы (например, аналитические отчёты, длящиеся часы), мастер вынужден сохранять все версии строк, необходимые этим запросам.

Сочетание двух параметров создаёт порочный круг: долгий запрос на реплике → задержка очистки на мастере → рост числа мёртвых кортежей → увеличение WAL при каждом DML. Даже если количество DML-операций не изменилось, каждая операция теперь генерирует больше WAL-данных из-за необходимости сохранять множество версий строк.

Диагностика проблемы

Чтобы убедиться, что причина именно в этом, выполните следующие шаги:

• Проверьте pg_stat_user_tables на мастере: посмотрите на число мёртвых кортежей (n_dead_tup) и время последнего VACUUM. Если мёртвых кортежей много, а VACUUM не успевает их очищать - гипотеза подтверждается.
• Проанализируйте pg_stat_replication на мастере: колонка write_lag и flush_lag покажут задержки репликации. Большие задержки говорят о том, что реплика не успевает применять WAL.
• Изучите логи реплики: ищите сообщения snapshot too old или canceling statement due to conflict with recovery - они указывают на конфликты, которые hot_standby_feedback пытается предотвратить.

Рекомендации по оптимизации

Если рост WAL критичен, рассмотрите следующие меры:

Сократите время выполнения запросов на реплике

Оптимизируйте медленные аналитические запросы: добавьте индексы, перепишите подсказки, используйте материализованные представления. Чем короче запрос, тем быстрее мастер сможет очистить мёртвые кортежи.

Настройте old_snapshot_threshold

Параметр old_snapshot_threshold (доступен с PostgreSQL 9.6) позволяет автоматически убивать слишком старые снимки данных на мастере. Например, установите old_snapshot_threshold = 1h - тогда мастер будет принудительно завершать транзакции, которые удерживают снимок дольше часа. Это снизит нагрузку на WAL, но может прервать некоторые долгие запросы на реплике.

Скорректируйте hot_standby_feedback

Если аналитические запросы на реплике не критичны для бизнеса, рассмотрите отключение hot_standby_feedback. При этом возрастут конфликты репликации, но WAL перестанет расти из-за мёртвых кортежей. Чтобы смягчить конфликты, увеличьте max_standby_streaming_delay (например, до 8-12 часов) - тогда реплика будет дольше ждать применения конфликтующих записей.

Увеличьте частоту VACUUM

Настройте более агрессивный autovacuum на мастере: уменьшите autovacuum_vacuum_scale_factor и autovacuum_vacuum_threshold. Это поможет быстрее очищать мёртвые кортежи, но увеличит нагрузку на CPU и I/O.

Используйте логическую репликацию

В некоторых случаях переход на логическую репликацию (Logical Replication) позволяет избежать проблем с мёртвыми кортежами, так как она не требует hot_standby_feedback и не блокирует VACUUM на мастере. Однако это более сложная в настройке архитектура.

Вывод

Комбинация hot_standby_feedback = on и max_standby_streaming_delay = 5h действительно может привести к двукратному росту WAL, если на реплике выполняются долгие аналитические запросы. Причина - задержка очистки мёртвых кортежей на мастере. Для решения проблемы оптимизируйте запросы, настройте old_snapshot_threshold или скорректируйте параметры репликации под вашу нагрузку.