Миграции схемы данных YDB с Flyway и распределенные блокировки

Мне кажется, что Docker образ Flyway не поддерживает кастомные расширения databaseType. (сущность, расширяющая flyway).

https://github.com/flyway/flyway-docker/issues/159 завел ишью по этому поводу.

Обратите внимание какие директории доступны flyway/libexec/lib 

гипотеза: /flyway/libexec/lib - зашита в образе

Спасибо вам за подробное разъяснение вашей проблемы!

Миграции схемы данных YDB с Flyway и распределенные блокировки

Добрый день!
Я воспроизвел вашу проблему у себя локально. И сделал пару наблюдений:
1. Не увидел flyway/libexec/lib в образе
2. Боюсь, что список баз данных в образе ограничен

Продолжу изучать вопрос.

Что нового в документации YDB во втором квартале 2024 года

Добрый день, ADO.NET доступен в Ydb.Sdk, начиная с версии 0.7.0. Вы можете использовать со связкой Dapper.

Миграции схемы данных YDB с Flyway и распределенные блокировки

Распределенные блокировки в Liquibase

Liquibase создает таблицу DATABASECHANGELOGLOCK, в которой содержится одна запись.

| ID | LOCKED | LOCKEDBY | LOCKGRANTED |
|:---|:-------|:---------|:------------|
| 1  | false  | null     | null        |

Блокировка для большинства СУБД происходит следующим образом:

-- acquire lock
SELECT LOCKED FROM DATABASECHANGELOGLOCK WHERE ID = 1;

-- Если false, делаем запрос на взятие блокировки

UPDATE DATABASECHANGELOGLOCK SET LOCKED = true .. WHERE ID = 1;

-- Если UPDATE вернул 0, то блокировку взять не удалось, повторим взятие блокировки через 1 секунду.

-- run migrations..

-- release lock
UPDATE DATABASECHANGELOGLOCK SET LOCKED = false WHERE ID = 1;

В текущем виде этот подход не позволит получить корректно распределенную блокировку для YDB, так как на данный момент UPDATE не возвращает количество обновленных строк. Этот способ становится рабочим, если взятие блокировки делать в транзакции уровня SERIALIZABLE. 

На этом уровне изоляции транзакция фиксирует состояние записи согласно модели MVCC. Если другая транзакция изменяет те же данные, текущая транзакция становится недействительной, поскольку она работала с уже неактуальной версией данных.

-- acquire lock
SELECT LOCKED FROM DATABASECHANGELOGLOCK WHERE ID = 1;

-- Если false, делаем запрос на взятие блокировки

UPDATE DATABASECHANGELOGLOCK SET LOCKED = true .. WHERE ID = 1;
COMMIT;

-- Transaction lock invalidated - означет, что блокировку не удалось взять, кто - то нас обогнал

Клиенты, которые не получили блокировку пытаются получить ее снова с интервалом 1 секунда.