web-dev-qa-db-fra.com

Réparation de voie de migration avec Spring Boot

Je ne comprends pas très bien ce que je suis censé faire lorsqu'une migration échoue à l'aide de Flyway dans un projet Spring Boot.

J'ai activé Flyway en ajoutant simplement la dépendance Flyway dans mon pom.xml. Et tout fonctionne bien. Mes scripts de base de données sont migrés lorsque je lance l'application Spring Boot.

Mais j'ai eu une erreur dans l'un de mes scripts et ma dernière migration a échoué. Maintenant, lorsque j'essaie de migrer, il y a une "incompatibilité de somme de contrôle de migration". Normalement, je courrais mvn flyway:repair, mais comme j'utilise Spring Boot, je ne suis pas censé utiliser le plug-in Flyway Maven. Alors, que suis-je censé faire?

il existe plusieurs façons d'effectuer une réparation sur la base de données. Personnellement, je préfère la simple instruction SQL.

Instruction SQL:

Supprimez simplement la ligne dont la migration a échoué. Après cela, vous pouvez réexécuter la migration.

Exécutez flyway directement

Vous pouvez installer Flyway local et exécuter flyway repair Dans la console

Utilisez le plugin Flyway Maven

Ajoutez le Flyway Maven Plugin à votre pom et exécutez mvn flyway:repair. Je ne pense pas que cela soit en contradiction avec le concept Spring Boot.

Étendre Spring Boot

Spring Boot appellera Flyway.migrate() pour effectuer la migration de la base de données. Si vous souhaitez plus de contrôle, fournissez un @Bean Qui implémente FlywayMigrationStrategy.

Dans FlywayMigrationStrategy, vous pouvez appeler la méthode migrate ou repair depuis flyway. Plus d'informations sont disponibles dans le Spring Boot Reference Guide .

Je ne pense pas que le FlywayMigrationStrategy dans l'application soit le bon endroit pour réparer la base de données. Une migration ayant échoué est une exception et doit être gérée en dehors de l'application.

24
Daniel Käfer

Plugin Flyway Maven

Juste pour ajouter cette information à la réponse de @ 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.

voie de migration mvn: propre

3.

voie de migration mvn: réparation

PS: si les étapes 2 et 3 ne fonctionnent pas, changez l'ordre.

Plus d'informations sur les objectifs de Maven: https://flywaydb.org/documentation/maven/

4
felipealves.gnu

Lorsque la migration de la base de données échoue, la migration est marquée comme ayant échoué dans la table d'historique de schéma (i.e flyway_schema_history) indiquant qu'un nettoyage manuel de la base de données peut être requis. Mais si la base de données prend en charge les transactions DDL, la migration est annulée automatiquement et rien n'est enregistré dans la table d'historique de schéma. PostgreSQL, Amazon Redshift, MS SQL sont quelques-unes des bases de données qui prennent en charge les transactions DDL alors que Oracle Database, MySQL, MariaDB, Amazon Aurora ne prend pas en charge les transactions DDL.

En cas d'échec des entrées de migration, il existe plusieurs options pour le réparer (applicable uniquement aux bases de données qui ne prennent PAS en charge les transactions DDL), comme décrit par @ daniel-käfer. Je veux en ajouter un autre (peut-être un moyen plus simple) pour faire face aux migrations ayant échoué.

Il existe plusieurs rappels pris en charge par flyway, afterMigrateError en fait partie. Si nous ajoutons un fichier sql avec le nom afterMigrateError.sql puis, il sera exécuté après chaque échec de migration. Par conséquent, nous pouvons simplement créer un fichier afterMigrateError.sql sur l'emplacement par défaut du dossier de migration de la base de données (resources/db/migration) avec la commande sql pour supprimer les migrations ayant échoué de flyway_schema_history table.

La commande sql afterMigrateError.sql peut être comme mentionné ci-dessous:

DELETE IGNORE FROM flyway_schema_history WHERE success=0;

Cette commande recherche la table flyway_schema_history s'il existe sinon il ne fera aucun changement. Ensuite, il recherche simplement les lignes qui ont une colonne success avec 0 entrée (en fait, cela se produit si la migration échoue, toute migration réussie aura une valeur 1 dans la colonne de réussite), puis supprimez ces entrées. Maintenant, nous pouvons simplement changer notre dernier fichier de migration et le corriger et l'exécuter à nouveau.

0
BishalG

Installez flyway localement comme dit ci-dessus , changez de répertoire dans l'installation puis lancez (exemple pour H2):

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