Pytanie Spowodowane przez: org.flywaydb.core.api.FlywayException: Sprawdzanie poprawności nie powiodło się. Migracja sumy kontrolnej niezgodności migracji 2


Próbowałem znaleźć rozwiązanie dla poniższego problemu, ale żaden z nich nie działał dla mnie. Rozwijam się Angular + Spring Boot zastosowanie aplikacji MySQL + flyway. Proszę wskazać, co tu jest nie tak.

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Validate failed. Migration Checksum mismatch for migration 2
-> Applied to database : 1499248173
-> Resolved locally    : -1729781252
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:296) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1054) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:829) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:538) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118) ~[spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1124) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1113) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at com.boot.App.main(App.java:9) [classes/:na]
Caused by: org.flywaydb.core.api.FlywayException: Validate failed. Migration Checksum mismatch for migration 2
-> Applied to database : 1499248173
-> Resolved locally    : -1729781252
    at org.flywaydb.core.Flyway.doValidate(Flyway.java:1108) ~[flyway-core-3.2.1.jar:na]
    at org.flywaydb.core.Flyway.access$300(Flyway.java:62) ~[flyway-core-3.2.1.jar:na]
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:1012) ~[flyway-core-3.2.1.jar:na]
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:1006) ~[flyway-core-3.2.1.jar:na]
    at org.flywaydb.core.Flyway.execute(Flyway.java:1418) ~[flyway-core-3.2.1.jar:na]
    at org.flywaydb.core.Flyway.migrate(Flyway.java:1006) ~[flyway-core-3.2.1.jar:na]
    at org.springframework.boot.autoconfigure.flyway.FlywayMigrationInitializer.afterPropertiesSet(FlywayMigrationInitializer.java:66) ~[spring-boot-autoconfigure-1.3.1.RELEASE.jar:1.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
    ... 18 common frames omitted

application.properties

logging.level.org.springframework.web=DEBUG

server.port=8080

spring.h2.console.enabled=true
spring.h2.console.path=/h2

## For H2 DB
#spring.datasource.url=jdbc:h2:file:~/dasboot
#spring.datasource.username=sa
#spring.datasource.password=
#spring.datasource.driver-class-name=org.h2.Driver

## For MYSQL DB
spring.datasource.url=jdbc:mysql://localhost:3306/dasboot
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

spring.datasource.max-active=10
spring.datasource.max-idle=8
spring.datasource.max-wait=10000
spring.datasource.min-evictable-idle-time-millis=1000
spring.datasource.min-idle=8
spring.datasource.time-between-eviction-runs-millis=1

flyway.baseline-on-migrate=true
spring.jpa.hibernate.ddl-auto=false;

#datasource.flyway.url=jdbc:h2:file:~/dasboot
#datasource.flyway.username=sa
#datasource.flyway.password=
#datasource.flyway.driver-class-name=org.h2.Driver


datasource.flyway.url=jdbc:mysql://localhost:3306/dasboot
datasource.flyway.username=root
datasource.flyway.password=root
datasource.flyway.driver-class-name=com.mysql.jdbc.Driver

pom.xml

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.3.1.RELEASE</version>
    </parent>

    <name>das-boot</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
        </dependency>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>
    </dependencies>

V2__create_shipwreck.sql

-- For H2 DB
--CREATE TABLE SHIPWRECK(
--  ID INT AUTO_INCREMENT,
--  NAME VARCHAR(255),
--  DESCRIPTION VARCHAR(2000),
--  CONDITION VARCHAR(255),
--  DEPTH INT,
--  LATITUDE DOUBLE,
--  LONGITUDE DOUBLE,
--  YEAR_DISCOVERED INT
--);

CREATE TABLE `dasboot`.`shipwreck` (
  `ID` INT NOT NULL AUTO_INCREMENT,
  `NAME` VARCHAR(255) NULL,
  `DESCRIPTION` VARCHAR(2000) NULL,
  `CONDITION` VARCHAR(255) NULL,
  `DEPTH` INT NULL,
  `LATITUDE` DOUBLE NULL,
  `LONGITUDE` DOUBLE NULL,
  `YEAR_DISCOVERED` INT NULL,
  PRIMARY KEY (`ID`));

enter image description here


15
2017-12-14 16:41


pochodzenie


Możliwy duplikat Flyway w bazie danych produkcyjnych - niedopasowanie sumy kontrolnej migracji - Adam


Odpowiedzi:


Flyway porównuje sumę kontrolną skryptu SQL z sumą kontrolną poprzednio uruchomioną. Ten wyjątek zwykle występuje, jeśli zmienisz skrypt SQL, który został już zastosowany przez Flyway, powodując niedopasowanie sumy kontrolnej.

Jeśli jest to programowanie, możesz usunąć bazę danych i rozpocząć migracje od zera.

Jeśli jesteś w produkcji, nigdy nie edytuj skryptów SQL, które zostały już zastosowane. Twórz tylko nowe skrypty SQL w przyszłości.


24
2017-12-14 16:48



Po prostu dokonuję migracji bazy danych z H2 DB do MYSQL. Następnie po prostu zaktualizowałem V2__create_shipwreck.sql. Proszę wskazać, jak mogę to rozwiązać. W powyższym poście edytowałem V2__create_shipwreck.sql. Nawet tabela rozbicia nie została utworzona w MYSQL.
Upuść bazę danych i uruchom ponownie Flywaya, a następnie przebuduje ją od nowa. - Kyle Anderson
Zwiń bazę danych? Jeśli masz dużo danych testowych? Drop nie jest rozwiązaniem. Działa, ale nie ma sposobu rozwiązania problemu. - Djalas
@Djalas Jak wskazuje moja odpowiedź, zmiany należy zawsze dodawać do nowych skryptów SQL, a nie istniejących skryptów SQL. - Kyle Anderson
Dostaję to, co masz na myśli. Ale jeśli wykonałeś kilka testów integracji przed błędem sumy kontrolnej. Upuszczenie bazy danych spowoduje wymazanie bazy danych i prawdopodobnie użytecznych danych testowych. Zastosowanie migracji nie zapewni danych testowych, testy integracyjne będą. Upuściłem czas w przeszłości, ale tylko wtedy, gdy nie dbam o dane przechowywane w mojej lokalnej instancji Postgres. - Djalas


Najlepszym rozwiązaniem byłoby wykonanie następujących kroków:

  1. Usuń plik o nazwie - V2__create_shipwreck.sql, clean i ponownie zbuduj projekt.
  2. Uruchom ponownie projekt, zaloguj się do h2 i usuń tabelę o nazwie "schema_version".

    upuść tabelę schema_version;

  3. Teraz zrób plik V2__create_shipwreck.sql z ddl i ponownie uruchom projekt ponownie.

  4. Pamiętaj o tym, dodaj wersję 4.1.2 dla rdzenia przelotu w pliku pom.xml

    <dependency>
        <groupId>org.flywaydb</groupId>
        <artifactId>flyway-core</artifactId>
        <version>4.1.2</version>
    </dependency>
    

Teraz powinno działać. Mam nadzieję, że to pomoże.


7
2018-04-11 10:56



Nie mogę usunąć schema_version. co powinienem zrobić? - Pavel
możesz usunąć tylko wiersz, z którym masz kłopoty, np: usuń z schema_version gdzie wersja = 2; - planben


Po prostu usunę z programu schema_version migrację, która różni się od migracji, która ma zostać zastosowana. W ten sposób nie wyrzucisz żadnych danych testowych, które możesz mieć.

Na przykład:

SELECT * from schema_version order by installed_on desc

V_005_five.sql
V_004_four.sql
V_003_three.sql
V_002_two.sql
V_001_one.sql

Migracje do zastosowania

V_005_five.sql
* V_004_addUserTable.sql *
V_003_three.sql
V_002_two.sql
V_001_one.sql

Rozwiązaniem jest tutaj usunięcie z schema_version

V_005_five.sql
V_004_four.sql

I przywróć wszelkie spowodowane zmiany bazy danych. na przykład jeśli utworzono nową tabelę schematu, należy ją usunąć przed rozpoczęciem migracji.

kiedy uruchomisz flyway, będzie on ponownie stosowany

V_005_five.sql
* V_004_addUserTable.sql *

nowa wersja schematu będzie

V_005_five.sql
* V_004_addUserTable.sql *
V_003_three.sql
V_002_two.sql
V_001_one.sql

Mam nadzieję, że to pomoże


3
2017-10-09 13:35





JEŚLI NIE JESTEŚ W PRODUKCJI, możesz zajrzeć do swojego flywayTable w bazie danych i usunąć wiersz, który zawiera nazwę zastosowanego skryptu.

flywayTable to opcja projektu, która definiuje nazwę tabeli w db używanej przez flyway, która zawiera informacje o wersji tego db, już stosowane skrypty ...


1
2018-03-30 13:52





W rzeczywistości istnieje inne rozwiązanie, ale jest to obejście problemu, którego nie należy wykonywać w prawidłowo zarządzanym projekcie. Jednak spotkałem się z sytuacją, w której nie można było zjechać lepszą drogą :)

Możesz zaktualizować tabelę schame_version i faktycznie zmienić sumę kontrolną na nową. Spowoduje to przejście migracji, ale może mieć inne skutki uboczne.

Podczas wdrażania w różnych środowiskach (test, uat, prod itp.) Może się zdarzyć, że musisz zaktualizować tę samą sumę kontrolną w innych środowiskach. A jeśli chodzi o gitflow i uwolnienie gałęzi, możesz łatwo wymieszać całość.


1
2018-01-22 12:01





Miałem ten sam problem i usunąłem kompletny schemat z bazy danych, ale problem pozostał.

Rozwiązałem to, uruchamiając repair() polecenie przelotu:

  flyway.repair();

Nie mogłem się dowiedzieć, co dokładnie poszło nie tak.


1
2018-06-06 10:52



gdzie napisałeś ten skrypt? - Sandeep R
To było po zainicjowaniu Flywaya, np. Flyway flyway = new Flyway (); flyway.setDataSource (dataSource); flyway.repair (); flyway.migrate (); - dave


Flyway zmienił sposób, w jaki oblicza sumy kontrolne z wersji 3 do wersji 5. Możesz ponownie obliczyć sumy kontrolne. Ponieważ wtyczka Flyway nie odczytuje prawidłowo właściwości źródła danych sprężyn, musisz ręcznie określić je w wierszu poleceń (lub jeden z wielu innych sposobów akceptowania przez Flyway).

mvn flyway:repair -Dflyway.user=root -Dflyway.password= -Dflyway.url=jdbc:mysql://localhost:3306/mydatabase -Dflyway.table=schema_version

Flyway zmienił również tabelę, w której zapisuje sumy kontrolne, więc musisz również określić flyway-table=schema_version używać starej tabeli, inaczej da ci ostrzeżenie (i prawdopodobnie błąd w wersji 6).

[INFO] Repairing Schema History table for version 2 (Description: create sources, Type: SQL, Checksum: 2125962141)  ...
[INFO] Repairing Schema History table for version 3 (Description: create stats, Type: SQL, Checksum: 389912194)  ...
[INFO] Repairing Schema History table for version 4 (Description: add user encrypted, Type: SQL, Checksum: 182607572)  ...

0
2017-08-01 18:11