Ответ 1

существует несколько способов выполнить ремонт базы данных. Я лично предпочитаю простой оператор SQL.

Заявление SQL:

Просто удалите строку с неудачной миграцией. После этого вы можете снова запустить миграцию.

Прямой пролетный путь

Вы можете установить Flyway local и запустить flyway repair в консоли

Использовать плагин Flyway Maven

Добавьте Flyway Maven Plugin к вашему pom и запустите mvn flyway:repair. Я не думаю, что это противоречит концепции загрузки Spring.

Расширить Spring Загрузка

Spring Загрузка вызовет Flyway.migrate(), чтобы выполнить миграцию базы данных. Если вы хотите больше управления, укажите @Bean, который реализует FlywayMigrationStrategy.

В FlywayMigrationStrategy вы можете вызвать метод переноса или восстановления с пролетного пути. Дополнительная информация доступна в Spring Справочном руководстве по загрузке.

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

Ответ 2

Плагин Flyway Maven

Просто чтобы добавить эту информацию в ответ @Daniel

1.

      ...
        <plugin>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-maven-plugin</artifactId>
            <version>4.1.0</version>
            <configuration>
                <url>jdbc:mysql://localhost:3306</url>
                <user>root</user>
                <password>root</password>
                <schemas>
                    <schema>[your_schema]</schema>
                </schemas>
            </configuration>
        </plugin>
      ...

2.

mvn пролет: чистый

3.

mvn пролет: ремонт

PS: Если шаги 2 и 3 не работают, измените порядок.

Дополнительная информация о целях maven: https://flywaydb.org/documentation/maven/

Ответ 3

Если миграция базы данных завершается неудачно, миграция помечается как неудачная в таблице истории схемы (ie flyway_schema_history) указывает на необходимость ручной очистки базы данных. Но если база данных поддерживает транзакции DDL, миграция откатывается автоматически и ничего не записывается в таблицу истории схемы. PostgreSQL, Amazon Redshift, MS SQL - это лишь некоторые из баз данных, которые поддерживают транзакции DDL, тогда как Oracle Database, MySQL, MariaDB, Amazon Aurora не поддерживают транзакции DDL.

В случае неудачных записей миграции существует несколько вариантов ее восстановления (применимо только для баз данных, которые НЕ поддерживают транзакции DDL), как описано в @daniel-käfer. Я хочу добавить еще один (может быть более простой способ), чтобы справиться с неудачными миграциями.

Есть несколько обратных вызовов, поддерживаемых afterMigrateError, afterMigrateError является одним из них. Если мы добавим файл sql с именем afterMigrateError.sql, он будет выполняться после каждого неудачного выполнения миграции. Следовательно, мы можем просто создать файл afterMigrateError.sql в расположении по умолчанию для папки миграции базы данных (resources/db/migration flyway_schema_history) с помощью команды sql, чтобы удалить неудачные миграции из таблицы flyway_schema_history.

Команда sql afterMigrateError.sql может быть такой, как указано ниже:

DELETE IGNORE FROM flyway_schema_history WHERE success=0;

Эта команда ищет таблицу flyway_schema_history если она существует, иначе она не изменится. Затем он просто ищет строки, в которых есть столбец success с записью 0 (на самом деле это происходит, если миграция завершается неудачно, все успешные миграции будут иметь значение 1 в столбце успеха), а затем удаляют такие записи. Теперь мы можем просто изменить наш последний файл миграции, исправить его и запустить снова.

Ответ 4

Установите flyway локально, как указано выше, перейдите в каталог установки и запустите (пример для H2):

./flyway -url=jdbc:h2:/Users/mugo/dev/h2/das-boot -user=sa -password= repair