Ответ 1
Хотя Flyway поддерживает откат (в качестве коммерческой функции), его использование не рекомендуется:
https://flywaydb.org/documentation/command/undo
Хотя идея отмены миграций хороша, к сожалению, на практике она иногда ломается. Как только у вас появятся деструктивные изменения (удаление, удаление, усечение,…), у вас начнутся проблемы. И даже если вы этого не сделаете, вы в конечном итоге создадите самодельные альтернативы для восстановления резервных копий, которые также должны быть надлежащим образом протестированы.
Отмена миграции предполагает, что вся миграция прошла успешно и теперь должна быть отменена. Это не помогает при сбоях версионных миграций в базах данных без транзакций DDL. Зачем? Миграция может потерпеть неудачу в любой момент. Если у вас есть 10 утверждений, возможно 1-е, 5-е, 7-е или 10-е не получится. Просто нет возможности узнать заранее. Напротив, отмененные миграции написаны для отмены всей версионной миграции и не помогут в таких условиях.
Альтернативный подход, который мы считаем предпочтительным, заключается в поддержании обратной совместимости между БД и всеми версиями кода, развернутого в настоящее время в производстве. Таким образом, неудачная миграция не является катастрофой. Старая версия приложения по-прежнему совместима с БД, поэтому вы можете просто откатить код приложения, исследовать и принять корректирующие меры.
Это должно быть дополнено правильной, хорошо протестированной стратегией резервного копирования и восстановления. Он не зависит от структуры базы данных, и как только он протестирован и доказал свою работоспособность, ни один скрипт миграции не сможет его сломать. Для достижения оптимальной производительности, и если ваша инфраструктура поддерживает это, мы рекомендуем использовать технологию моментальных снимков вашего базового решения для хранения данных. Особенно для больших объемов данных, это может быть на несколько порядков быстрее, чем традиционные резервные копии и восстановления.