VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

Melkij, спасибо!
Когда vacuum отрабатывает долго (несколько суток), за время его работы накапливаются уже другие dead_tuples. Карта видимости приходит в "негодность" (ведь процесс до конца еще не завершен)? Или он будет работать с той картой которая была актуальна на момент начала процесса?

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

Melkij,

- читаем табличку последовательно от 0 блока

А карта видимости, на каком этапе будет использована?

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

Melkij

Поглядывать за wraparound. Если грозит - тогда index_cleanup = off чтобы отодвинуть горизонт и затем дать вакууму работать дальше над индексами.

Я правильно понял, что придется при этом оборвать VACUUM который уже какое-то время проработал? Иначе index_cleanup = off не сделать, он же будет заблокирован. Или это ничего страшного?

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

Melkij, благодарю, исчерпывающе.

Так называемые micro vacuum и index hint bits, когда даже select может чего-нибудь писать в WAL.

Про hint bits слышал, про micro vacuum нет, стОит наверное почитать исходники, хотя бы комментарии.

Еще раз спасибо.

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

Melkij,

Но бизнесовая проблема 100% в другом и не формулируется как "включить hot_standby_feedback".

Да, вы правы формулировка действительно была совсем иная. Человек который эти параметры включал, хотел чтобы "запросы на реплике не отменялись".

не только

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

Повезёт если бонусом не ляжет вообще всё из-за замедления ответов СУБД. Некоторые проекты красиво складываются минут за 20.

Пока третью неделю держимся...

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

Спасибо за ответ.

Это заведомо ведёт к замедлению и мастера и каждой реплики. hot_standby_feedback мешает работать автовакуумам, препятствуя удалению старых версий строк, именно для этого эта настройка и нужна.

Да, понимаю и принимаю этот факт, но ничего поделать не могу - бизнес потребовал. Команда разработки пока оптимизировать эти запросы не может (косячная архитектура приложения).

У вас ещё и размеры базы скоро подрастут без сторонних причин, особенно если много update. По той же самом причине добавления помех в работе автовакуума.

Да, уже наблюдаю.
Update в пик если брать - за 1 час набегает 18 млн. update, delete - 160 млн. insert - 230 млн. - это все за 1 час.
Не знаю много ли это, не с чем сравнить.

Объём записи WAL так же может добавит

За счет того что автовакууму обрабатывать больше мертвых версий строк или не только?

Как балансировать запросы на чтение между репликами, если на уровне приложения разделить запросы на чтение и запись невозможно?

rPman, приложение не только читает конечно же. Но идея в том, чтобы с помощью стороннего инструмента отделить чтение от записи, и только чтение балансировать между репликами. Или это невозможно сделать с помощью стороннего инструмента? Разные данные - не особо страшно. Тем более чтобы это купировать я наверное могу использовать синхронную реплику.

Как балансировать запросы на чтение между репликами, если на уровне приложения разделить запросы на чтение и запись невозможно?

Вы имеете ввиду вертикальное масштабирование?

Как балансировать запросы на чтение между репликами, если на уровне приложения разделить запросы на чтение и запись невозможно?

rPman, нет, пока еще не преступил. Как мне показалось, pgpool-II довольно сложен в настройке, может есть более простой путь? И почему именно master-master? Я собирался балансировать именно чтение, зачем master?

p.s. вы смотрели, где именно и почему тормозят запросы? может там очень плохо построены индексы?

Да, с этой стороны уже все более менее оптимизировано. Запросы короткие, но их много.

Как балансировать запросы на чтение между репликами, если на уровне приложения разделить запросы на чтение и запись невозможно?

mayton2019, владелец "черного ящика" сам инициировал данную оптимизацию. А можно поподробнее, в каком случае может сломаться бизнес-логика?

Как балансировать запросы на чтение между репликами, если на уровне приложения разделить запросы на чтение и запись невозможно?

shurshur, у pgpool есть и другие ограничения, поэтому я и ищу возможный другой подход. Если его нет - то лучше отказаться от этой идеи.

Что почитать по системному администрированию?

pódde, т.е ответить вам по сути нечего?

Куда движется профессия системного администратора?

А я вот не очень согласен с вами, если честно.

Как грамотно архивировать данные?

И еще вопрос. Можно ли натыкать жестких дисков в порты на материнской плате ? Не будет ли это никак "конфликтовать" с рейд контроллером.

Как грамотно архивировать данные?

Хорошо, спасибо. На отделенное устройство - какое ? Бэкапиться на ЮСБ жесткий диск, мне кажется, не очень надежное решение, поэтому и задумался о NAS. Бэкапить буду примерно 500-600 гб. sql server базы, поэтому боюсь за производительность.