I have an existing database. I created two migrations
$ ls src/main/resources/db/migration/
V1__create_stats.sql V2__create_sources.sql
I set the following in application.properties
# Prevent complaints when starting migrations with existing tables.
flyway.baselineOnMigrate = true
Otherwise it would give the error org.flywaydb.core.api.FlywayException: Found non-empty schema
galaxybadgewithout metadata table! Use baseline() or set baselineOnMigrate to true to initialize the metadata table.
When I try to start the app, it skips the migrations and doesn't execute them! I use show tables;
in MySQL and see they are not there!
>mvn spring-boot:run
...
2018-05-09 18:43:03.671 INFO 24520 --- [ restartedMain] o.f.core.internal.util.VersionPrinter : Flyway 3.2.1 by Boxfuse
2018-05-09 18:43:04.420 INFO 24520 --- [ restartedMain] o.f.c.i.dbsupport.DbSupportFactory : Database: jdbc:mysql://localhost:3306/galaxybadge (MySQL 5.5)
2018-05-09 18:43:04.486 INFO 24520 --- [ restartedMain] o.f.core.internal.command.DbValidate : Validated 0 migrations (execution time 00:00.030s)
2018-05-09 18:43:04.704 INFO 24520 --- [ restartedMain] o.f.c.i.metadatatable.MetaDataTableImpl : Creating Metadata table: `galaxybadge`.`schema_version`
2018-05-09 18:43:05.116 INFO 24520 --- [ restartedMain] o.f.core.internal.command.DbBaseline : Schema baselined with version: 1
2018-05-09 18:43:05.145 INFO 24520 --- [ restartedMain] o.f.core.internal.command.DbMigrate : Current version of schema `galaxybadge`: 1
2018-05-09 18:43:05.146 INFO 24520 --- [ restartedMain] o.f.core.internal.command.DbMigrate : Schema `galaxybadge` is up to date. No migration necessary.
I looked at this answer but it didn't help and seemed to give the wrong property name. Here is the schema_version
table it created.
> select * from schema_version;
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+
| version_rank | installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+
| 1 | 1 | 1 | << Flyway Baseline >> | BASELINE | << Flyway Baseline >> | NULL | root | 2018-05-09 18:43:05 | 0 | 1 |
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+
Spring Boot 1.5.6, FlyWay Core 3.2.1
Spring docs - FlyWay docs
If not specified in schemas, Flyway will automatically attempt to create and clean this schema first. This schema will also be the default for the database connection (provided the database supports this concept).
The hotfix migration can be deployed with Flyway with skipExecutingMigrations=true . The schema history table will be updated with the new migration, but the script itself won't be executed again. skipExecutingMigrations can be used with with cherryPick to skip specific migrations.
Run Flyway migration tests Once you've pushed all your scripts to GitHub, you can now manually run the migration test workflow by navigating to the Actions tab in GitHub and clicking on 'Database migration test', then 'Run workflow'.
OK I found this https://flywaydb.org/documentation/existing
But didn't follow it. Instead, I moved my migrations from V1__*
and V2__*
to V2...
and V3...
and downloaded the production schema into V1__initialize.sql
.
mysqldump -h project.us-east-1.rds.amazonaws.com -u username -p --no-data --skip-add-drop-table --compact --skip-set-charset databasename > V1__initialize.sql
Then when I ran Spring mvn spring-boot:run
it ran the migrations.
(Well actually there was a lot of debugging of the SQL and I had to drop the tables several times and delete rows out of schema_verion
and delete old file names from target/.../migration/
but that's another story.)
I believe it may be possible to set
flyway.baselineVersion=0
and skip the SQL dump (initialization) based on the info here: https://flywaydb.org/documentation/configfiles. However, having the schema available for future devs seems like the right approach.
I still don't understand why it didn't run V2__...
migration from the original question. If it starts at 1, then migration 2 is still available to run. Had it worked as expected, then I might have understood the problem sooner.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With