flyway repair: Fix the Schema History Table
flyway repair deletes failed migration rows from the schema history and updates stored checksums to match the files on disk.
When a migration fails partway on a non-transactional database, its row lingers as Failed and blocks future runs. repair clears that state so migrate can proceed.
What it does
flyway repair does two things: it removes entries for failed migrations from flyway_schema_history, and it realigns the checksums and descriptions of applied migrations with the current files. It does not touch your actual tables or data.
Common usage
# after a failed migrate on MySQL (no DDL transactions)
flyway -url=jdbc:mysql://db:3306/app \
-user=ci -password="$DB_PASSWORD" repair
flyway repair && flyway migrateOptions
| Flag | What it does |
|---|---|
| -url / -user / -password | Connection details |
| -locations=<list> | Locations used to recompute checksums |
| -table=<name> | Name of the schema history table if not the default |
In CI
repair is a recovery command, not a routine step. If a pipeline needs repair on every run, the underlying migration is failing repeatedly and should be fixed. On PostgreSQL, DDL runs in a transaction so failed migrations roll back cleanly and rarely leave a Failed row; MySQL and Oracle need repair more often.
Common errors in CI
repair itself fails with "Unable to obtain connection" when credentials are wrong. If migrate still reports a checksum mismatch after repair, the -locations differ between the two runs so repair recomputed against the wrong files. Confirm both commands use the same locations and working directory.