Как один небольшой "недогляд" привёл к проблеме после миграции базы с MS SQL на PostgreSQL через ibcmd
Обычно я пишу про то, как нужно делать, но сегодня напишу про то как НЕ нужно!))
При этом я остаюсь верен себе и пишу только про свою практику, а соответственно этой мой недогляд...
Итак, всё было хорошо, процесс миграции протестирован минимум 10 раз!
Настало время миграции прода и по началу казалось что всё прекрасно, сама миграция завершилась сообщением "[INFO] Репликация информационной базы успешно завершена"!
Ура, можно выдыхать!
Но буквально через несколько минут от пользователей посыпались жалобы что в некоторых справочниках задвоились данные...
Не веря глазам своим идём на СУБД и запрашиваем выборку из справочника (на картинке) и видим, что действительно, задвоенные записи с одинаковым значением поля _code и при этом разными значениями поля version...
Сначала было желание просто заново смигрировать, но пользователи уже работают в базе, меняют данные и так решили не делать...
Достаточно долго просто удивлялись - как так то!?!?!? И что это вообще такое!?!?!?
Затем, проанализировав масштаб проблемы, выяснилось что она есть только в двух справочниках и только у предопределённых элементов.
В документации написано, что эти элементы создаются "сами из конфигурации" , если при обращении к ним их нет в базе данных.
Вот это поворот! Откуда тогда эти элементов по 2 версии??? И почему только в этих справочниках, а с остальными предопределёнными всё хорошо?
Развязка:
Оказалось, что мигрируя базу мы НЕ заблокировали базу назначения!
И пользователи начали заходить в базу в момент миграции, некоторые предопределенные элементы ещё не успели приехать с MS SQL и были заполнены значениями из конфигурации, а потом ещё приехали через ibcmd в процессе миграции и записались с новой версией...
Удалили "неверные" элементы, получили в некоторых документах "ссылки на несуществующий объект" и были уверены что победили!
Но не тут то было!
Такие записи продолжили появляться в базе...
Заблокировали базу, все пользователи вышли, зашли заново - не помогло.
У кого то всё равно по 2 значения с одинаковым кодом в справочниках, у кого-то по одному, а при этом в СУБД то уже ТОЧНО по одному значению!
Опять в документацию - там написано что надо бы обновить конфигурацию и тогда счастье наступит...
Но выгонять пользователей опять было очень неприятно, поэтому решили попробовать мягкий перезапуск всех рпхостов в надежде что в новые процессы будет затянут уже новый контекст конфигурации и всё починится...
И да, действительно, всё починилось!!!
❗Вывод: База назначения при миграции должна быть надёжно заблокирована от входа пользователей до того момента, пока миграция не закончится!
Обычно я пишу про то, как нужно делать, но сегодня напишу про то как НЕ нужно!))
При этом я остаюсь верен себе и пишу только про свою практику, а соответственно этой мой недогляд...
Итак, всё было хорошо, процесс миграции протестирован минимум 10 раз!
Настало время миграции прода и по началу казалось что всё прекрасно, сама миграция завершилась сообщением "[INFO] Репликация информационной базы успешно завершена"!
Ура, можно выдыхать!
Но буквально через несколько минут от пользователей посыпались жалобы что в некоторых справочниках задвоились данные...
Не веря глазам своим идём на СУБД и запрашиваем выборку из справочника (на картинке) и видим, что действительно, задвоенные записи с одинаковым значением поля _code и при этом разными значениями поля version...
Сначала было желание просто заново смигрировать, но пользователи уже работают в базе, меняют данные и так решили не делать...
Достаточно долго просто удивлялись - как так то!?!?!? И что это вообще такое!?!?!?
Затем, проанализировав масштаб проблемы, выяснилось что она есть только в двух справочниках и только у предопределённых элементов.
В документации написано, что эти элементы создаются "сами из конфигурации" , если при обращении к ним их нет в базе данных.
Вот это поворот! Откуда тогда эти элементов по 2 версии??? И почему только в этих справочниках, а с остальными предопределёнными всё хорошо?
Развязка:
Оказалось, что мигрируя базу мы НЕ заблокировали базу назначения!
И пользователи начали заходить в базу в момент миграции, некоторые предопределенные элементы ещё не успели приехать с MS SQL и были заполнены значениями из конфигурации, а потом ещё приехали через ibcmd в процессе миграции и записались с новой версией...
Удалили "неверные" элементы, получили в некоторых документах "ссылки на несуществующий объект" и были уверены что победили!
Но не тут то было!
Такие записи продолжили появляться в базе...
Заблокировали базу, все пользователи вышли, зашли заново - не помогло.
У кого то всё равно по 2 значения с одинаковым кодом в справочниках, у кого-то по одному, а при этом в СУБД то уже ТОЧНО по одному значению!
Опять в документацию - там написано что надо бы обновить конфигурацию и тогда счастье наступит...
Но выгонять пользователей опять было очень неприятно, поэтому решили попробовать мягкий перезапуск всех рпхостов в надежде что в новые процессы будет затянут уже новый контекст конфигурации и всё починится...
И да, действительно, всё починилось!!!
❗Вывод: База назначения при миграции должна быть надёжно заблокирована от входа пользователей до того момента, пока миграция не закончится!