Как откатить миграцию с помощью Flyway?

Ответ 1

Хотя Flyway поддерживает откат (в качестве коммерческой функции), его использование не рекомендуется:

https://flywaydb.org/documentation/command/undo

Хотя идея отмены миграций хороша, к сожалению, на практике она иногда ломается. Как только у вас появятся деструктивные изменения (удаление, удаление, усечение,…), у вас начнутся проблемы. И даже если вы этого не сделаете, вы в конечном итоге создадите самодельные альтернативы для восстановления резервных копий, которые также должны быть надлежащим образом протестированы.

Отмена миграции предполагает, что вся миграция прошла успешно и теперь должна быть отменена. Это не помогает при сбоях версионных миграций в базах данных без транзакций DDL. Зачем? Миграция может потерпеть неудачу в любой момент. Если у вас есть 10 утверждений, возможно 1-е, 5-е, 7-е или 10-е не получится. Просто нет возможности узнать заранее. Напротив, отмененные миграции написаны для отмены всей версионной миграции и не помогут в таких условиях.

Альтернативный подход, который мы считаем предпочтительным, заключается в поддержании обратной совместимости между БД и всеми версиями кода, развернутого в настоящее время в производстве. Таким образом, неудачная миграция не является катастрофой. Старая версия приложения по-прежнему совместима с БД, поэтому вы можете просто откатить код приложения, исследовать и принять корректирующие меры.

Это должно быть дополнено правильной, хорошо протестированной стратегией резервного копирования и восстановления. Он не зависит от структуры базы данных, и как только он протестирован и доказал свою работоспособность, ни один скрипт миграции не сможет его сломать. Для достижения оптимальной производительности, и если ваша инфраструктура поддерживает это, мы рекомендуем использовать технологию моментальных снимков вашего базового решения для хранения данных. Особенно для больших объемов данных, это может быть на несколько порядков быстрее, чем традиционные резервные копии и восстановления.

Ответ 2

Это поддерживается начиная с Flyway 5.0. К сожалению, это только коммерческая функция.

https://flywaydb.org/documentation/command/undo

Ответ 3

Я предполагаю, что вам нужна стратегия отката, когда, например, партнер не работает на стадии производства, и его развертывание имеет важное значение для вашего выпуска.

Вы могли бы назвать свои сценарии SQL-пролетов следующим образом:
V <YourReleaseNumber> .000_ < описание > .sql

Теперь вы можете покинуть
V <YourReleaseNumber> .998_rollback.sql для отката
и делают V <YourReleaseNumber> .999_reenroll.sql для повторной установки.

В вашей среде CI/CD вам нужно еще 2 задания (с ручным запуском) после задания развертывания. Один для отката, который запускает процесс отката, включая миграцию пролетного пути. Другое для повторного прокрутки.
Вам просто нужно заботиться о целевой конфигурации в пролете.
Для вашего задания на развертывание ваша цель должна быть <YourReleaseNumber> .997
Для вашего задания отката <YourReleaseNumber> .998

При запуске новой версии убедитесь, что вы не будете запускать откат/повторное подключение script старой версии.

Как сказано выше, хорошо протестированная стратегия резервного копирования и восстановления является рекомендуемым решением.

(sry для плохой английский)

Ответ 4

Я нашел, что лучший способ сделать это - просто очистить базу данных и перенести ее на определенную версию, на которую вы хотели вернуться.

Как часто задаваемые вопросы, сценарии отката являются хорошими теоретически, но некоторые миграции просто невозможно отменить. (например, если таблица отбрасывается, восстановление DDL таблицы легко, но восстановление данных, содержащихся в нем, может быть затруднено.)