Кейс: деплой упал на validate, потому что миграцию поправили руками

Миграция V15 давно применена в проде. Кто-то заметил в ней опечатку, открыл файл и поправил прямо в репозитории — без новой версии миграции, просто «маленький фикс». На следующем деплое Flyway остановился на этапе validate с FlywayException: checksum mismatch.

Flyway хранит в таблице flyway_schema_history checksum каждой применённой миграции и при каждом запуске сверяет его с текущим содержимым файла. Как только применённая миграция считается фактом истории — редактировать её файл нельзя, даже если исправление тривиальное.

Правильный путь — новая миграция с фиксом, а не правка старой. flyway repair пересчитывает checksum и снимает блокировку, но делает это, скрывая реальное изменение истории — в проде это риск, а не решение.

SELECT version, checksum FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;

Что спросят следом: что будет, если два инстанса сервиса запустятся одновременно и оба попытаются применить миграции. Flyway берёт advisory lock прямо в БД на время выполнения миграций — второй инстанс просто ждёт, пока первый закончит.

Применённая миграция — это факт истории, а не черновик, который можно поправить.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки