Question 114320 in PostgreSQL Question posted in
The official documentation can be found here.

Postgresql – flyway version migration issues from 6.3.1 to 8.5.x using docker container

Team,

We have working flyway docker image (flyway community edition version 6.x) setup for postgresql 11.x version working. After upgrading our postgresql version to 14.x and now the existing flyway migration scripts (with updated community edition version 8.x) were failing with ‘ERROR: Validate failed: Migrations have failed validation’ error.

    - ingestionTime: 1665114622336
    message: Flyway Community Edition 8.4.1 by Redgate
    timestamp: 1665114621897
  - ingestionTime: 1665114622336
    message: 'Database: jdbc:postgresql://aws-rds-dev:5432/myapp (PostgreSQL 14.4)'
    timestamp: 1665114621898
  - ingestionTime: 1665114622336
    message: 'ERROR: Validate failed: Migrations have failed validation'
    timestamp: 1665114622186
  - ingestionTime: 1665114622336
    message: 'Detected applied migration not resolved locally: create trigger to update universal table. If you removed this migration intentionally, run repair to mark the migration as deleted.'
    timestamp: 1665114622186

Are there any document how we can migrate the version schema table entries if we upgrade the postgresql database?

Any help on this highly appreciated.

Thanks in advance..

Tags:

2

Answers


  1. 0

    This is the result of a change introduce in Flyway V7. Before V7 missing repeatable migrations were ignored and didn’t cause a validation error and after V7 they are no longer ignored

    To resolve this and retain the previous behaviour you need to set ignoreMigrationPatterns="*:missing" which will prevent missing migrations from throwing a validation error. You can find the documentation for this parameter here

    It’s worth noting that missing migrations aren’t ignored by default as it’s not recommended to remove migrations as this affects the reproducibility of your database. If you did mean to remove the migration then running repair to mark it as deleted in the schema history table would be the preferred option

    Login or Signup to reply.
  2. 0

    In addition to the accepted answer (I wonder why official documentation doesn’t explain this): I found it hard to learn how to trigger repair, so what I did in my Spring Boot project was create a @Configuration class with this method:

        @Bean
    @Profile(SpringProfile.MS_SQL)
    public FlywayMigrationStrategy repairBeforeMigrateStrategy() {
        return flyway -> {
            flyway.repair();
            flyway.migrate();
        };
    }

    The rest of flyway options are configured in our project via application.yml file.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search