Flyway 4.2.0 Параллельный отказ нескольких узлов с Oracle 11g

У меня есть несколько серверов приложений, настроенных для запуска пролетного пути при запуске. Каждый сервер пытается применить один и тот же набор миграций к нескольким схемам в одной базе данных Oracle 11g. Эти серверы запускаются одновременно. Это работает в большинстве случаев. Однако иногда сервер выходит из строя во время миграции из-за нарушения уникального ограничения.

Невозможно вставить строку для версии '0' в таблицу метаданных "FOO". "SCHEMA_VERSION"

Состояние SQL: 23000 Код ошибки: 1 Сообщение: ORA-00001: ограничение уникальности (FOO.SCHEMA_VERSION_pk) нарушено

    at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addAppliedMigration(MetaDataTableImpl.java:242)
    at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addBaselineMarker(MetaDataTableImpl.java:334)
    at org.flywaydb.core.internal.command.DbBaseline$2.call(DbBaseline.java:135)
    at org.flywaydb.core.internal.command.DbBaseline$2.call(DbBaseline.java:112)
    at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
    at org.flywaydb.core.internal.command.DbBaseline.baseline(DbBaseline.java:112)
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:990)
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:971)
    at org.flywaydb.core.Flyway.execute(Flyway.java:1464)
    at org.flywaydb.core.Flyway.migrate(Flyway.java:971)

...

Я думал, что пролетный путь сможет справиться с этой ситуацией, основываясь на следующем:

https://flywaydb.org/documentation/faq#parallel

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

Есть ли параметр, который может гарантировать, что версия схемы заблокирована, или это ошибка?

Класс OracleTable блокирует таблицу в монопольном режиме. Следует ли добавить предложение NOWAIT и обработать возникающее исключение Oracle?


java flyway oracle11g
person user581638    schedule 14.07.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Он должен работать. Мы тестируем это с каждой сборкой, и поведение без NOWAIT - это то, что нам нужно (блокировка до снятия блокировки). Если вы можете достоверно воспроизвести это или увидеть явную ошибку в нашем коде, пожалуйста, обязательно сообщите об ошибке с необходимыми деталями в системе отслеживания проблем.

person Axel Fontaine    schedule 14.07.2017
comment
В моем случае оба экземпляра пролетного пути пытаются выполнить одни и те же миграции. Допустим, первый пролетный путь ожидает второго пролетного пути, который находится в процессе миграции V1.0.0 в схему FOO. Похоже, что первый пролетный путь пытается перейти на V1.0.0 после того, как второй завершается и разблокирует таблицу, что вызывает нарушение уникального ограничения. Кажется, что он должен проверить перед миграцией, как обычно. - person user581638; 15.07.2017