Как бороться с ранее действующими миграциями Flyway, которые стали недействительными - PullRequest
Новая
       55

Как бороться с ранее действующими миграциями Flyway, которые стали недействительными

0 голосов
/ 22 апреля 2020

У меня есть приложение Spring Boot, которое использует Flyway для миграции баз данных в Postgres.

Сейчас ему около четырех лет, поэтому мы говорим о Flyway 4.0.3, Spring Boot 1.3.x и Postgres 9.х. Версии, вероятно, можно было бы обновить, но я бы хотел исправить все существующие проблемы, прежде чем делать это.

В то же время, Postgres был повышен до уровня выше 9.x. К сожалению, при этом некоторые из существующих миграций устарели, поскольку содержат устаревший синтаксис. Так что теперь запуск приложения с базой данных fre sh (то есть в среде разработки) приводит к сбоям этих миграций. В производстве это нормально, поскольку эти миграции уже были применены и больше не будут применяться.

Мне любопытно, каковы лучшие методы go по этому поводу. Я не могу просто go и исправить синтаксис в существующих миграциях, так как это приведет к сбою контрольных сумм в производственной среде. Я знаю, repair - вещь, но я не уверен, как она работает и как ее использовать с Spring Boot.

Failing SQL: 

UPDATE config
SET (description) = 'my description'
WHERE ...

Правильно SQL: 

UPDATE config
SET description = 'my description'
WHERE ...

Ошибка: 

Message    : ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression

РЕДАКТИРОВАТЬ 24/04/2020 Решение Spring Boot:

После того, как Грант Фитчи отправил правильный ответ о как использовать repair для этого ниже, я просто добавлю, как я делал это специально с Spring Boot. Я только что создал компонент FlywayMigrationStrategy, который вызывает repair перед вызовом migrate: 

@Bean
public FlywayMigrationStrategy cleanMigrateStrategy() {
    return flyway -> {
        flyway.repair();
        flyway.migrate();
    };
}

При развертывании этого в производственной среде во время запуска контрольные суммы в таблице schema_versions в Postgres были исправлены. В другой версии я снова удалю строку flyway.repair();, так как в противном случае это, очевидно, создаст риск применения недопустимых миграций.

1 Ответ

1 голос
/ 22 апреля 2020

Вы ищете вариант ремонта. Я не знаю напрямую, как вызвать его с помощью весенней загрузки, но документация находится здесь . Это должно позаботиться о том, что вы ищете.

Так что первым шагом в этом случае будет исправление миграций, чтобы они правильно выполнялись в среде разработки. Теперь разработка должна быть в порядке, и пролет должен успешно мигрировать.

На производстве вы должны получить ошибку проверки, поскольку контрольные суммы различаются. Ремонт Flyway будет «восстанавливать» таблицу истории схемы так, чтобы сохраненные контрольные суммы совпадали с новыми на диске, и, следовательно, проверка прохода прошла снова. В частности, при восстановлении пролетного пути таблица истории схемы соответствует тому, что имеется на диске. Он обновляет все контрольные суммы для примененных миграций до контрольных сумм тех, которые у вас есть на диске (и, следовательно, используйте это, только если вы уверены, что изменения идентичны). Он также удаляет все неудачные записи миграции из таблицы (опять же, используйте это только после того, как вы очистили базу данных самостоятельно).

...