Флаг блокировки запуска скриптов обновления при старте приложения и запуске нескольких инстансов

Вопросы и проблемы
#1

Добрый вечер.
Экспериментирую с запуском и эксплуатацией приложения в openshift в режиме одновременного запуска нескольких подов с uberjar на борту.
Столкнулся с проблемой, возникшей при деплое новой версии приложения в которой были изменения в БД.
Openshift одновременно перезапустил поды в итоге первый поднявшийся под начал процедуру миграции БД, а остальные упали из ошибок скриптов миграции (схема базы уже обновлена).
В liquibase для таких случаев предусмотрен специальный флаг, говорящий о том, что процес миграции уже идет. Есть ли подобный механизм в CUBA?

Какие еще меня могу ждать сюрпризы из-за отхода от рекомендуемых способов развертывания в таком режиме?

#3

Добрый день!

В CUBA предусмотрена блокировка выполнения миграции БД с помощью взаимодействия в кластере через JGroups. При одновременной работе нескольких экземпляров приложения кластер рекомендуется настроить в любом случае, иначе могут быть проблемы с синхронизацией параметров и кэшей. Если кластер работает, то скрипты миграции БД будет запускать только сервер-мастер.

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

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

Если захотите доработать механизм блокировки так чтобы он работал как в Liquibase - загляните в бин DbUpdateManager, его можно легко переопределить в проекте.