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
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.