Есть PostgreSQL 15, используется мастер и реплика в режиме hot-standby.
Параметры hot-standby такие: max_standby_streaming_delay = 5h, hot_standby_feedback = on.
Эти параметры недавно применили, и после было замечено, что стало в два раза больше генерироваться WAL. Могла ли комбинация данных настроек привести к увеличению количества WAL-сегментов? Потому что судя по отчету pg_profile - DML-операций не стало больше, но долгие аналитические запросы на реплику приходят довольно часто.
Если нужно, могу прислать другие настройки ведомого и ведущего сервера.
На аналитической реплике не должно быть hot_standby_feedback. Это заведомо ведёт к замедлению и мастера и каждой реплики. hot_standby_feedback мешает работать автовакуумам, препятствуя удалению старых версий строк, именно для этого эта настройка и нужна.
У вас ещё и размеры базы скоро подрастут без сторонних причин, особенно если много update. По той же самом причине добавления помех в работе автовакуума.
Это заведомо ведёт к замедлению и мастера и каждой реплики. hot_standby_feedback мешает работать автовакуумам, препятствуя удалению старых версий строк, именно для этого эта настройка и нужна.
Да, понимаю и принимаю этот факт, но ничего поделать не могу - бизнес потребовал. Команда разработки пока оптимизировать эти запросы не может (косячная архитектура приложения).
У вас ещё и размеры базы скоро подрастут без сторонних причин, особенно если много update. По той же самом причине добавления помех в работе автовакуума.
Да, уже наблюдаю.
Update в пик если брать - за 1 час набегает 18 млн. update, delete - 160 млн. insert - 230 млн. - это все за 1 час.
Не знаю много ли это, не с чем сравнить.
Объём записи WAL так же может добавит
За счет того что автовакууму обрабатывать больше мертвых версий строк или не только?
hot_standby_feedback бизнес потребовать не мог. Это не бизнесовая задача. Выстрел себе в ногу в попытке починить сломавшийся или нестабильно работающий бизнес-процесс - да. Но бизнесовая проблема 100% в другом и не формулируется как "включить hot_standby_feedback".
За счет того что автовакууму обрабатывать больше мертвых версий строк или не только?
не только, но первопричина вернётся к этому.
Повезёт если бонусом не ляжет вообще всё из-за замедления ответов СУБД. Некоторые проекты красиво складываются минут за 20.
Есть такая штука как full page image (FPI) - при первом изменении страницы после чекпойнта записывается в WAL копия всей страницы, а не только изменение этой страницы. (это защита для crash recovery на тот случай, если IO записало страницу только частично, страница у нас 8кб типично, страница памяти ОС чаще 4кб, а у диска адресация может быть и 512 байт: поэтому нужно предполагать, что есть ли мы попросили записать 8кб и где-то тут всё умерло, то на дисках может быть уже записано, например, 4кб нового содержимого страницы, а других 4кб остались старые - в итоге фигня)
Из менее очевидного и не помню чтобы задокументированного (помимо исходников), часть работы автовакуума подхватит выполнение других запросов. Так называемые micro vacuum и index hint bits, когда даже select может чего-нибудь писать в WAL. Небольшие оптимизации вида "ну это не моя работа, я выполняю запрос, но блок данных вот он в руке, всю работу по проверке видимости транзакций всё равно уже сделал, подпишу для потомков примечания чтобы они не тратили время на то же самое"
Ситуация вокруг hot_standby_feedback или max_standby_streaming_delay (max_standby_archive_delay полностью аналогично, но применяется на restore_command) в postgresql такая:
Реплика получает поток WAL, сделанных на мастере и обнаруживает, что на мастере физически из датафайла удалены данные (обычно автовакуумом), которые ещё может хотеть прочитать запрос, запущенный на этой реплике. Пропустить это изменение и накатывать репликацию дальше нельзя. Дальнейшшие изменения запросто могут быть в этом же самом датафайле, уже полагающиеся что это изменение было применено. Остаётся не так уж много вариантов что может делать реплика:
• или приостанавливать репликацию и подождать пока доработает запрос
• или отменять запрос и продолжать применять репликацию
postgresql сначала делает паузу репликации, затем по прошествии времени max_standby_streaming_delay отменяет мешающие запросы с разными вариантами terminating connection due to conflict with recovery. При этом, max_standby_streaming_delay считается от начала конфликта репликации и по таймауту снимает совсем всех кто мешает, даже если этот конкретный запрос запустился полсекунды назад.
hot_standby_feedback же это третий вариант работы, он предписывает реплике отправлять на мастер сведения о своей самой старой транзакции. Мастер это учитывает в своей работе и не удаляет данные, которые потенциально та транзакция может ещё запросить. То есть активно мешает оперативной работе автовакуума, от чего копятся ненужные версии строк в таблицах и индексах, занимают место и замедляют обработку всех запросов, и на мастере и на всех физических репликах (т.к. запрос должен проверить, вдруг эта версия строки видна именно ему)
Для аналитической реплики выбирается комфортный max_standby_streaming_delay. Полчаса, час, 10 часов - индивидуально по потребностям проекта. Баланс между "дать запросам поработать" и "реплика может отставать на такое время и это не авария, а полностью штатное поведение, о котором мы с вами ранее договорились"
