Антон Дорошкевич | маяк в мире 1С и СУБД

Как один небольшой "недогляд" привёл к проблеме после миграции базы с MS SQL на PostgreSQL через ibcmd

Обычно я пишу про то, как нужно делать, но сегодня напишу про то как НЕ нужно!))
При этом я остаюсь верен себе и пишу только про свою практику, а соответственно этой мой недогляд...

Итак, всё было хорошо, процесс миграции протестирован минимум 10 раз!

Настало время миграции прода и по началу казалось что всё прекрасно, сама миграция завершилась сообщением "[INFO] Репликация информационной базы успешно завершена"!
Ура, можно выдыхать!

Но буквально через несколько минут от пользователей посыпались жалобы что в некоторых справочниках задвоились данные...
Не веря глазам своим идём на СУБД и запрашиваем выборку из справочника (на картинке) и видим, что действительно, задвоенные записи с одинаковым значением поля _code и при этом разными значениями поля version...

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

Достаточно долго просто удивлялись - как так то!?!?!? И что это вообще такое!?!?!?

Затем, проанализировав масштаб проблемы, выяснилось что она есть только в двух справочниках и только у предопределённых элементов.

В документации написано, что эти элементы создаются "сами из конфигурации" , если при обращении к ним их нет в базе данных.

Вот это поворот! Откуда тогда эти элементов по 2 версии??? И почему только в этих справочниках, а с остальными предопределёнными всё хорошо?

Развязка:
Оказалось, что мигрируя базу мы НЕ заблокировали базу назначения!
И пользователи начали заходить в базу в момент миграции, некоторые предопределенные элементы ещё не успели приехать с MS SQL и были заполнены значениями из конфигурации, а потом ещё приехали через ibcmd в процессе миграции и записались с новой версией...

Удалили "неверные" элементы, получили в некоторых документах "ссылки на несуществующий объект" и были уверены что победили!

Но не тут то было!
Такие записи продолжили появляться в базе...
Заблокировали базу, все пользователи вышли, зашли заново - не помогло.
У кого то всё равно по 2 значения с одинаковым кодом в справочниках, у кого-то по одному, а при этом в СУБД то уже ТОЧНО по одному значению!

Опять в документацию - там написано что надо бы обновить конфигурацию и тогда счастье наступит...

Но выгонять пользователей опять было очень неприятно, поэтому решили попробовать мягкий перезапуск всех рпхостов в надежде что в новые процессы будет затянут уже новый контекст конфигурации и всё починится...
И да, действительно, всё починилось!!!

❗Вывод: База назначения при миграции должна быть надёжно заблокирована от входа пользователей до того момента, пока миграция не закончится!

У многих сервисов был свой дом в Яндексе....
Тёплый, уютный, надёжный!
Желаю всем кто сейчас восстанавливает эти ит-дома и работает на пределе физических возможностей огромной удачи, чтобы всё получалось с первого раза!
Я уверен, что все ИТ-шники сейчас с вами!
❤️❤️❤️

https://max.ru/id7729445882_biz/AaEcCIPHOmk

Обновление минорной версии PostgreSQL – практически обязательно!

Обычно к обновлению минорной версии ПО (последняя цифра в номере версии) относятся как к необязательной процедуре вычитывая новшества и примеряя их на себя.
Но за последние несколько месяцев, и это по моему мнению пока самое полезное применение Больших Лингвистических Моделей (ИИ, хотя он ещё вообще не ИИ))) ) в ИТ, с помощью ИИ найдено очень большое количество уязвимостей в самом широком спектре ПО.

Огромный плюс ИИ в этой работе в том, что он не ленив и не чурается старого кода, в котором все были уверены на протяжении десятков лет и код ревью человека туда никогда бы не заглянул.

В последних минорных версиях PostgreSQL 18.6, 17.11, 16.15, 15.19 и даже в 14.24 исправили 32 CVE!

❗Обратной стороной ИИ в ИТ является использование найденных уязвимостей с генерацией сценариев использования с нечеловеческой скоростью, поэтому обновления, которые раньше можно было отложить, теперь откладывать нельзя!

Как понять хватает ли памяти серверу PostgreSQL 2.0

Ранее мы уже получили верхнеуровневую информацию о заполненности кэша СУБД
https://max.ru/explorer1c/AZ4g2XVbeoY

Но этой информации не всегда достаточно чтобы принять решение хватает ли нам уже выделенного объёма.

Тут нам на помощь приходит ещё один столбец из pg_buffercache_summary(), а именно usagecount_avg, который даёт информацию о среднем значении счётчика использования буферов в кэше.

select usagecount_avg from pg_buffercache_summary()

Сам процесс "нагревания" и "охлаждения" буферного кэша основан на алгоритме Clock-Sweep.

Краткий смысл алгоритма:
Процесс "нагревания" - при каждом обращении к странице в кэше счётчик её использования (usage_count) увеличивается на единицу.

Чтобы избежать зацикливания в бесконечном круге горячих страниц максимальное значение ограничено, например в postgresql, числом 5.

Процесс "охлаждения" - циклически обходим страницы в буферном кэше.
- Если usage_count > 0, то уменьшаем его значение на единицу.
- Если usage_count = 0, то эта страница может быть вымещена из кэша, а на её место загружена новая.

Таким образом эффективность кэша можно оценить значением usagecount_avg > 2,5.
Если же значение usagecount_avg часто оказывается меньше единицы, то буферного кэша недостаточно и страницы постоянно оттуда вымещаются.
Сильно высокое значение usagecount_avg (4-5) наоборот говорит о том, что у нас слишком большой буферный кэш и его можно уменьшить.

Более подробную раскладку, какое количество страниц с каким значением счётчика в кэше можно получить запросом:

select usage_count, buffers from pg_buffercache_usage_counts()

Получив, например такой расклад:
usage_count | buffers
0 | 441196
1 | 236729
2 | 81823
3 | 44989
4 | 214970
5 | 159941

При этом usagecount_avg = 1,86

❗Конечно и это ещё не вся информация для тончайшей настройки PostgreSQL, но надеюсь что она даст ещё больше понимания как работает кэш и что с ним можно делать и нужно ли это делать.

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