由 org.flywaydb.core.api 引起。 FlywayException: 验证失败。迁移校验和不匹配2

小开

Flyway is comparing the checksum of the SQL script with that of the previously run checksum. This exception typically occurs if you change a SQL script that has already been applied by Flyway, thus causing a checksum mismatch.

If this is development, you can drop your database and start the migrations from scratch.

If you're in production, never edit SQL scripts that have already been applied. Only create new SQL scripts going forward.

小开

IF YOU ARE NOT IN PRODUCTION, you can look in your flywayTable in the data base and remove the line which contain the name of the script which has been applied.

flywayTable is a project option which define the name of the table in the db used by flyway which contain information about the version of this db, already applied scripts...

小开

The best solution would be to do these steps :

Delete the file called - V2__create_shipwreck.sql, clean and build the project again.
Run the project again, login into h2 and delete the table called "schema_version".

drop table schema_version;
Now make V2__create_shipwreck.sql file with ddl and rerun the project again.

Do remember this, add version 4.1.2 for flyway-core in pom.xml like

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

It should work now. Hope this will help.

小开

I would simply delete from schema_version the migration/s that deviates from migrations to be applied. This way you don't throw away any test data that you might have.

For example:

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

Migrations to be applied

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

Solution here is to delete from schema_version

V_005_five.sql
V_004_four.sql

AND revert any database changes caused. for example if schema created new table then you must drop that table before you run you migrations.

when you run flyway it will only re apply

V_005_five.sql
* V_004_addUserTable.sql *

new schema_version will be

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

Hope it helps

小开

Update your schema_version record to mach the "Resolved locally" value which in your case is -1729781252

小开

Actually there is another solution, but it's a workaround, that should not be done in a properly managed project. However I met a situation, where it was not possible to go down the better road :)

You can update the schame_version table, and actually change the checksum to the new one. This will cause the migration to go through, but can have other side effects.

When deploying to different environments (test, uat, prod, etc) then it might happen, that you have to update the same checksum on more environments. And when it comes to gitflow, and release branches, you can easily mix up the whole.

小开

I had the same issue and deleted the complete schema from the database, yet the issue remained.

I solved this by running the repair() command of flyway:

flyway.repair();

Alternatively with Flyway Maven plugin:

mvn flyway:repair

Maven plugin addition into pom.xml:

<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
</plugin>

BTW: I did not find what exactly went wrong.

With Gradle (as per comment from Raf):

./gradlew flywayRepair

小开

Flyway changed the way it calculates the checksums from version 3 to version 5. You can re-calculate the checksums. Since the Flyway plugin doesn't properly read the Spring datasource properties, you have to manually specify them on the command line (or one of the other various ways Flyway accepts).

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

Flyway also changed the table it stores the checksums, so you also have to specify flyway-table=schema_version to use your old table, or else it will give you a warning (and probably an error in version 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)  ...

小开

If you are sure that the modification in the SQL file has no impact on your existing schema, you can also update the checksum of the existing schema.

I did this following a slight change in the sql file.

Here is how I updated the checksum:

update flyway_schema_history set checksum = '-1934991199' where installed_rank = '1';

小开

simple solution will be change spring.datasource.url=jdbc:h2:file:~/dasboot in application.properties to new file name like : spring.datasource.url=jdbc:h2:file:~/dasboots

小开

1-Delete the migration file. 2-connect to your database and drop the table created by the migration. 3-recreate the file of the migration with the the right sql.

小开

I had the same issue and I believe this occurred because of checksum between linux and windows (also mac). you can use repair() command in flyway.

flyway.repair();

Be careful , if you are in production environment , make sure that you did not change the migration SQL file; because when you run the flyway.repair(); it means you saying to flyway that your are sure about the migration version and their checksum and then the flyway repair them !

小开

Here the solution which worked for me when I had this issue in my local system.

Go to flyway_schema_history in your DB
Delete the row containing the sql migration script

小开

If you have your problem in production, you must have V2__create_shipwreck.sql identically to the one you have in your latest version where it has not been modified.

Then the checksum will be correct again

小开

Just add

spring.flyway.enabled=false

in application.properties file if you do not want flyway to check the checksum every time you run the application.

小开

use this query in your local DB.

select * from schema_version delete from schema_version where checksum Column = -1729781252;

Note: -1729781252 is the "Resolved locally" value.
Build and start the server.

小开

What I did when faced this issue, was connect to DB and update the checksum field correspondent to the mistaken version, putting there the value resolved locally by FlyWay.

For the following error:

nested exception is org.flywaydb.core.api.FlywayException: Validate failed.
Migration Checksum mismatch for migration 1.12
-> Applied to database : 1029320280
-> Resolved locally    : -236187247

I simply did this:

UPDATE schema_version SET checksum = -236187247 WHERE version_rank = 12 AND checksum = 1029320280;

And problem solved..

NOTE: You have to be sure your schema is actually correct, check your tables and their structure, if everything is OK, then you can apply this solution; otherwise, you should repair your schema manually first using plain and native SQL.

小开

I had the same issue and tried all the options (delete schema, delete specific row, update checksum) but nothing works.

In my case flyway-core dependency got corrupted somehow.

Solution:

Delete flyway-core folder from ~.m2\local repository path...\org\flywaydb\flyway-core.
Execute "maven clean install" so that it will download new one and add it into a project.

I hope this will help.

小开

There are 3 ways to solve this issue while development. Any one from below can solve this issue.
1) provide the changes in new migration sql file with incrementing version
2) change the schema name in db url we provide
datasource.flyway.url=jdbc:h2:file:~/cart3
datasource.flyway.url=jdbc:h2:file:~/cart4
3) delete the .mv and .trace files in users home directory
ex: cart3.mv and cart3.trace under c://users/username/

小开

just don't validate:

flyway.setValidateOnMigrate(false);

小开

After your .sql applied to DB, you edited the .sql, flyway may show this error.

If using Postgresql, a quick solution

After dropping tables "flyway_schema_histrory" and the table my .sql created, the error disappeared. delete table

小开

I fixed this error with these three steps:

In your database, go to the flyway_schema_history table
Delete the last row containing the most recent flyway migration script ("V6__xxx" or whatever)

Start your application again. I got another flyway error message that was kind of a dump of SQL to insert some rows in some tables.

Go to those tables and delete those new rows.

I think the flyway migration script was trying to run again, but it had already run once, was trying to do the same thing again - insert the same rows, and that was the final conflict/error. Deleting those rows allowed it to run normally/successfully

小开

I have faced similar issue once. And the solution was...

Don't do any changes to DAO classes.. .It will try to change the database and flyway will not allow.