Нужна небольшая дополнительная информация, но типичные причины и способы проверки/починки — ниже. Ответ содержит быстрый чек‑лист и команды для логирования, которые обычно сразу показывают проблему.
Сначала уточните (это поможет быстро pinpoint):
- Какая версия Spring Boot и Flyway?
- Какие зависимости в pom.xml (вставьте org.flywaydb:flyway-core и spring-boot-starter-data-jpa и/или jdbc присутствуют?)
- Где лежат миграции (путь в resources)? Как называются файлы (пример: V1__init.sql)?
- Используете ли несколько DataSource'ов?
- Что показывают логи при старте (включите DEBUG для Flyway/AutoConfiguration)?
Чек‑лист причин и исправлений
1) Flyway не добавлен как runtime‑зависимость
- Проверьте, что в pom.xml есть org.flywaydb:flyway-core (обычно Spring Boot Starter авто‑подхватывает, но если вы добавляли только плагин — это не то же самое).
- Пример: <dependency>org.flywaydb:flyway-core</dependency>
2) Нет DataSource/нет JDBC starter
- Flyway запускается только если есть DataSource bean. Если вы не используете spring-boot-starter-jdbc или не настроили DataSource через Spring, Flyway не будет запущен.
- Решение: добавить spring-boot-starter-jdbc / корректно сконфигурировать spring.datasource.url/user/password.
3) Местоположение/имена миграций неправильные
- По умолчанию Flyway ищет classpath:db/migration и файлы вида V1__descr.sql.
- Убедитесь, что файлы лежат в src/main/resources/db/migration и имеют корректные имена. Иначе Flyway стартует, но не увидит миграций (в логах это видно).
4) Flyway действительно запускается, но вы этого не замечаете
- Flyway может запускаться без видимого эффекта (если версий нет). Включите логирование: logging.level.org.flywaydb=DEBUG и/или logging.level.org.springframework.boot.autoconfigure.flyway=DEBUG.
5) Конфликт с Hibernate (ddl-auto)
- Если у вас spring.jpa.hibernate.ddl-auto=create или create-drop, Hibernate может пересоздавать/удалять схему после запуска Flyway. Решение: переключить ddl-auto=none или validate и управлять схемой через Flyway, либо установить:
spring.jpa.defer-datasource-initialization=true
(чтобы отложить инициализацию JPA до выполнения Flyway — полезно в Spring Boot 2.5+).
6) Отключён автоконфиг (exclude)
- Проверьте, не указано ли в @SpringBootApplication или свойствах spring.autoconfigure.exclude параметр, отключающий FlywayAutoConfiguration.
7) Несколько DataSource
- При наличии более одного DataSource Flyway по‑умолчанию не знает, к какому подключиться. Нужно либо сконфигурировать spring.flyway.* для конкретного DataSource (url/user/password), либо создать бин Flyway вручную и задать DataSource/locations.
8) Свойство записано в неправильном месте/профиле
- Убедитесь, что spring.flyway.enabled=true находится в application.properties/application.yml того профиля, который реально используется, и что оно не переопределяется (например, application-{profile}.properties или переменными окружения).
9) Использовали только Maven/Gradle плагин
- Плагин Flyway для сборки (maven‑flyway-plugin) выполняет миграции при билде, но не добавляет библиотеку в runtime. Для запуска при старте приложения нужна зависимость flyway-core.
Как диагностировать быстро
- Включите логирование:
logging.level.org.flywaydb=DEBUG
logging.level.org.springframework.boot.autoconfigure.flyway=DEBUG
- Посмотрите при старте строки вида "Flyway init" / "Current version of schema" или сообщения об ошибках.
- Убедитесь, что в логах есть AutoConfiguration для Flyway (FlywayAutoConfiguration).
Если хотите, пришлите: pom.xml (зависимости), application.properties, вывод логов при старте — тогда скажу точнее что именно не даёт Flyway запуститься.