Добрый день друзья! Тут вопрос связанный с autovacuum и wraparound,

база у нас достаточно большая, сейчас возникла проблема с заполнением вакума, если его увеличить с дефолтных значений (3) до 10, насколько он замедлит систему? Спасибо за ответ!

Добрый день, а вы убедились что действиетельно не хватает воркеров и таблицы встают в очередь на обработку?

Настраивал 30 (ну, чисто чтобы пользователям ещё коннектов оставалось). У нас ускорило. Ну, когда этих 30-ти хватало :)

> сейчас возникла проблема с заполнением вакума Эээ... с чем? > Если его увеличить с дефолтных значений (3) до 10 Кого "его"? Количество workers? Если да, то на некоторое время насколько-то замедлит (а потом ускорит, скорее всего). ;) Вообще, правильный общий подход при проблемах с autovacuum — делать так, чтобы его было больше. Т.е., в первую очередь, чтобы сам он был агрессивнее (и, возможно, использовать больше workers).

Ошибка на это указывает: ERROR: database is not accepting commands to avoid wraparound data loss in database "raid"

можете уточнить что имеете ввиду под словом агрессивнее?

🫠 не совсем на это. Ваша ошибка указывает на то что ваш администратор провтыкал все предупреждения и довел базу до предаварийного состояния. Вам сюда, в частности в раздел "Immediate Action: When PostgreSQL Service Has Shutdown Due to Transaction Wraparound"

У autovacuum есть немало настроек: SELECT * FROM pg_settings WHERE category = 'Autovacuum'; Их стоит "выкрутить" так, чтобы он осуществлял больше работы за единицу времени. Лично я бы в подобной ситуации начал с отключения autovacuum_vacuum_cost_delay, например.

он не будет нагружать cpu?

(В дополнение к предыдущему сообщению) В таком случае — после того, как разберётесь с этой проблемой. Кстати, какая там версия PostgreSQL?

вот кстати про cost_delay... у автовакуума есть т.н. failsafe режим, при котором автовакуум становится еще злее - начинает пропускать очистку индексов, и игнорирует cost_delay (см. vacuum_failsafe_age)

Будет, и это прекрасно.

Есть... но только с v14 (я в том числе поэтому спросил Sherzodbek Kirgizbaev про версию PostgreSQL).

14.4

сейчас запустили процесс увеличения autovacuum_max_workers до 10 в режиме single user mode, как я понял, потом можно будет failsafe режим активировать?

Вобще-то, чаще всего на средненагружэнных плохомониторящихся базах до проблем с вропэраундом доходит не из-за вакуума! А из-за горизонта транзакцый.

А должна быть 14.9 (но major version достаточно новая, чтобы там много чего хорошего на тему autovacuum уже было). А в остальном — я бы на Вашем месте разобрался, как этой базе удалось до этого дойти... Вы можете результат запроса SELECT name, setting, context, source, boot_val, reset_val FROM pg_settings WHERE name LIKE '%vacuum%' ORDER BY name; показать? После того, как устраните неотложную проблему, я имею в виду...

В single user mode это бесполезно, насколько я помню — читайте то, что Вам посоветовали, и делайте то, что там написано. Разбирательствами будете заниматься потом. ;)

спасибо, сейчас пока ждем когда завершится процесс начнем анализ.

Добрый день, вопрос по autovacuum опять, вчера когда обновляли параметры в single-user mode, за сутки обработал только 9000 транзакций из ~3 млн. Потом включаем failsafe regime, а он выдает такую ошибку: 2023-10-05 10:05:03.405 +05 [9697] ERROR: database is not accepting commands to avoid wraparound data loss in database "raid" 2023-10-05 10:05:03.405 +05 [9697] HINT: Stop the postmaster and vacuum that database in single-user mode. Можете подсказать в чем может быть проблема?

и где нужно копать?

без FATAL ?

Вот эту процедуру вакуума в синглмоде надо сделать во всех базах. Это не очевидно, т.к. оно не показывает(не показывало) название подключенной базы в командной строке.

пока да

Но, у нас только одна база, который включает несколько схем.

Обычно в Postgres есть как минимум три базы - postgres/template0/template1

psql -l

vacuum вообще-то не транзакцыи обрабатывает, откуда вы взяли эти числа (9000, 3млн)?

админ так говорит

что можно сделать с горизонтом?

Если этим занимается "админ" — то вы тут при чём? Боюсь, пытаться воспринять что-то через "испорченный телефон" приведёт только к дополнительным затратам.

все вместе ищем

Выяснить, что там повисло. Если сервер рестартовали — это соответственно не долгая транзакцыя на сервер. Или prepared transaction, или hot_standby_feeedback от зависшэй реплики. (Впрочем, про то, убирается ли hot_standby_feedback от рестарта — я не помню).

Но всё-таки ответ, что они имеет в виду и откуда взял числа 9000 и 3млн — важэн. Можэт показать, что вы там делаете.

из этих логов

Ну, не скриншотом жэ! Кстати, это наоборот — отсчёт до совсем фиаско. Так что это не "обработано", это "вропэраунд приблизился на 9000 транзакцый из 3млн". И вообще, там вон в HINT всё написано.

Про hot_standby_feedback, кстати — удобно включать ручку old_snapshot_threshold во что-нибудь типа 1d, тогда такого не будет на средненагружэнной базе. Можэте прямо сейчас включить, со слотами потом разберётесь.

Не надо включать эту "ручку" — она достаточно вероятно приводит к corruption и т.п., в связи с чем эта feature выпилена из будущих версий PostgreSQL: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f691f5b80a85c66d715b4340ffabb503eb19393e

Послушайте... Вам же сразу https://t.me/pgsql/501951 ответили, что Вам нужно делать, нет? Почему вот это вот (то, что Вы пишете далее) всё ещё продолжается, почему Вы до сих пор не устранили проблему?! ;)

Ещё не вечер — к 17 вернут, думаю, так или иначе.

Не вернут (я подозреваю, что Вы на это надеетесь оттого, что не знаете "замечательную" историю её внедрения) — именно в v17 она и "выпилена".

В статье, кстати, примерно ничего про то, как искать stale slots и prepared transactions. Понятно, что в перкону с таким редко обращаются, но...

Историю — не знаю, да. Она выпилена пока что не из 17, а из head, который через год приведёт к 17.

У авторов семь пятниц на неделе, да.

> Историю — не знаю, да. Как раз эта история, собственно, [разнообразно] печальна, и практически гарантирует то, что этой "feature" в PostgreSQL мы больше не увидим. ;(

По тому, что пишет Sherzodbek Kirgizbaev, у меня создаётся впечатление, что они до этого просто не дошли, т.е. не сделали того, что советуют статья и документация PostgreSQL, и даже эти HINTs — "Stop the postmaster and vacuum that database in single-user mode" (а вместо того всё что-то "копают" и "ищут"). ;(

товарищи из data egret и других консалтеров читают этот тред, потирая руки: скоро к ним придёт очередной клиент с воплем "заплачу любые деньги только верните базу" :)

Неужто им такие "треды" на работе не надоели? ;)

Просто у нас новая система на PostgreSQL, а все старые на Oracle, думали справимся.

начали процесс по статье

И справились бы, если бы читали, что Вам пишут... даже в сообщениях об ошибках. ;( Что касается документации: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND https://www.postgresql.org/docs/current/app-postgres.html#APP-POSTGRES-SINGLE-USER и совсем же несложно, нет? Т.е. я правильно понял, что Вы до этого до сих пор не дошли (не начали), база у Вас так и не работает?

Не придёт. Была бы остро нужна база — пошли искать бы кого-нибудь ещё позавчера.