Почему увеличилась генерация WAL?

Приветствую!

Есть PostgreSQL 15, используется мастер и реплика в режиме hot-standby.
Параметры hot-standby такие: max_standby_streaming_delay = 5h, hot_standby_feedback = on.
Эти параметры недавно применили, и после было замечено, что стало в два раза больше генерироваться WAL. Могла ли комбинация данных настроек привести к увеличению количества WAL-сегментов? Потому что судя по отчету pg_profile - DML-операций не стало больше, но долгие аналитические запросы на реплику приходят довольно часто.

Если нужно, могу прислать другие настройки ведомого и ведущего сервера

0

WAL больше не стало - изменив параметры Вы увеличили лаг очистки ну или проблемы с сетью (реплика сильно отстаёт)

1

fte65, если сравнить по отчету pg_profile периоды когда эти параметры были выключены и периоды когда включены, в разделе WAL Statisctics как раз можно увидеть, что стало именно больше сегментов WAL, количественно. Это все при незначительном увеличении количества DML.

0

Сообщение от bsd9 DML-операций не стало больше

Совершенно не показатель. Можно буквально за одну операцию обновить всю таблицу или влить пачку новых данных, сгенерировав при этом тонну wal

1

Сообщение от katamoto Совершенно не показатель. Можно буквально за одну операцию обновить всю таблицу или влить пачку новых данных, сгенерировав при этом тонну wal

Понимаю, но я бы тогда в pg_profile видел запросы, которые обновили целиком таблицу или загрузили пачку данных, но их нет.

0

Мне представляется, что включение feedback запросто может повлечь увеличение WAL на основном сервере.
Даже в документации это написано: https://www.postgresql.org/doc... Y-FEEDBACK

hot_standby_feedback (boolean)

Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby. This parameter can be used to eliminate query cancels caused by cleanup records, but can cause database bloat on the primary for some workloads.

Предположим раньше этот параметр не был включен. Это значит, что запроса на реплике (скорее всего это построение каких-то отчетов) прерывались, если это порождало конфликты с приходящими с оноснвого сервера изменениями в WAL. Теперь вы поставили этот параметр. Ваш резервный сервер стал отправлять обратно на основной сервер информацию о выполняемых на нем запросах. Можно считать, что это инфа о блокировках, чтобы раньше разрешать потенциальные конфликты на основном сервере. Это откладывает выполнение каких-то транзакций, сервер должен больше хранить WAL, до ротации при очередных плановых и неплановых контрольных точках. В результате действительно может увеличиваться.

Я бы для проверки замерял не абсолютное значение, а скорее скорость увеличения или уменьшения WAL. Если на реплике мало отчетной нагрузки скорее всего скорость роста WAL будет уменьшаться до каких-то приемлимях для вас значений. Если наоборот много, то скорее всего вы будете наблюдать рост.

0

Сообщение от grgdvo but can cause database bloat on the primary for some workloads.

Это же про bloat, или вы имеете ввиду что с bloat autovacuum должен делать больше работы?

Сообщение от grgdvo Ваш резервный сервер стал отправлять обратно на основной сервер информацию о выполняемых на нем запросах.

Да, он отравляет мастеру свой xmin.

Сообщение от grgdvo Я бы для проверки замерял не абсолютное значение, а скорее скорость увеличения или уменьшения WAL.

Что вы имеете ввиду, измерить количество WAL в секунду?

0

Про bloat я имею в виду, что это приводит к распуханию не в смысле увеличения мертвых строк (баласта), а в принце распухания по размеру. WAL же растет, мы стали меньше его ротировать, потому что приходится ждать отклика от реплик.

WAL можно измерять по абсолютной величине - сумма размеров всех файлов в заданный момент времени.
А можно по разнице размеров между текущим и предыдущим моментом времени - это изменение размера во времени или скорость увеличения/уменьшения.

1