Обновление Flyway 4.2.0 -> 5.0.0 выполнить миграцию не удалось, даже если указан flyway.table - PullRequest
Новая
       9

Обновление Flyway 4.2.0 -> 5.0.0 выполнить миграцию не удалось, даже если указан flyway.table

1 голос
/ 24 апреля 2019

Я обновляю ряд зависимостей maven, которые отстали в нашем приложении, и сталкиваюсь с проблемой обновления с flyway-maven-plugin 4.2.0, в которой наши команды сброса и переноса завершаются сбоем так, как я могу ' Найти полезные результаты для.

Первоначально я пытался перейти с 4.2.0 на 5.2.4. Когда мне не удалось устранить мою ошибку, я вернулся к одной версии, поднявшейся до 5.0.0. Следуя примечаниям к выпуску 5.0.0, я добавил flyway.table=schema_version в мои файлы flyway- $ env.properties и обновил команды Makefile для использования -Dflyway.configFiles=

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

Команда make выполняет следующее: 

@mvn -pl db flyway:repair \
    -Dflyway.url="jdbc:mysql://${FLYWAY_TARGET_HOST}:${FLYWAY_TARGET_PORT}/${FLYWAY_TARGET_DB}?useUnicode=true&characterEncoding=utf8&useSSL=false" \
    -Dflyway.password=${FLYWAY_TARGET_DB_PW} \
    -Dflyway.user=${FLYWAY_TARGET_DB_USER} \
    -Dflyway.configFiles="src/main/resources/config/flyway/${FLYWAY_CONFIG_FILENAME}.properties"
@mvn -pl db flyway:migrate \
    -Dflyway.url="jdbc:mysql://${FLYWAY_TARGET_HOST}:${FLYWAY_TARGET_PORT}/${FLYWAY_TARGET_DB}?useUnicode=true&characterEncoding=utf8&useSSL=false" \
    -Dflyway.password=${FLYWAY_TARGET_DB_PW} \
    -Dflyway.user=${FLYWAY_TARGET_DB_USER} \
    -Dflyway.configFiles="src/main/resources/config/flyway/${FLYWAY_CONFIG_FILENAME}.properties"

При запуске на пустой БД предоставляется следующий вывод: 

[INFO] --- flyway-maven-plugin:5.0.0:migrate (default-cli) @ db ---
[INFO] Flyway Community Edition 5.0.0 by Boxfuse
[INFO] Database: jdbc:mysql://localhost:3306/db_test (MySQL 5.7)
[INFO] Successfully validated 46 migrations (execution time 00:00.029s)
[INFO] Creating Schema History table: `db_test`.`schema_version`
[WARNING] Could not find schema history table `db_test`.`schema_version`, but found `db_test`.`schema_version` instead. You are seeing this message because Flyway changed its default for flyway.table in version 5.0.0 to flyway_schema_history and you are still relying on the old default (schema_version). Set flyway.table=schema_version in your configuration to fix this. This fallback mechanism will be removed in Flyway 6.0.0.
[INFO] Current version of schema `db_test`: << Empty Schema >>
[INFO] Migrating schema `db_test` to version 1.0 - DbBaseline
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.799 s
[INFO] Finished at: 2019-04-23T18:12:57-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:5.0.0:migrate (default-cli) on project db: org.flywaydb.core.internal.exception.FlywaySqlException: 
[ERROR] Unable to lock table `db_test`.`schema_version`

1 Ответ

0 голосов
/ 24 апреля 2019

После ясного взгляда на этот вопрос проблема заключалась в нашем скрипте V1.0, а именно в том, что мы отбрасывали и воссоздали схему перед созданием таблиц.Это привело к тому, что сгенерированная таблица flyway не появилась после применения сценария V1.0.

После удаления этой строки все задания flyway выполняются без ошибок.К счастью, пролетный путь: ремонт исправляет контрольную сумму в таблице schema_version без каких-либо взломов или ручного редактирования БД.

...