java - name - ¿Cómo revertir las migraciones usando Flyway?
flyway tutorial (4)
Las migraciones de MyBatis dividen cada archivo SQL en dos secciones:
- Uno para migrar una versión hacia adelante.
- Una para migrar de nuevo una versión.
¿Cómo se puede revertir las versiones usando Flyway ?
Encontré la respuesta en la FAQ :
¿Qué pasa con los scripts de degradación / migraciones a la baja?
Flyway NO admite scripts de degradación.
Si bien la idea de los scripts de degradación (popularizados por Rails Migrations) es buena en teoría, desafortunadamente se descompone en la práctica. Tan pronto como tenga cambios destructivos (soltar, eliminar, truncar, ...), comenzará a tener problemas. E incluso si no lo hace, termina creando alternativas caseras para restaurar copias de seguridad, que también necesitan ser probadas adecuadamente.
Los scripts de degradación suponen que la migración completa ha fallado.
Una migración puede fallar en cualquier punto. Si tiene 10 afirmaciones, es posible que falle la 1ª, la 5ª, la 7ª o la 10ª. Simplemente no hay manera de saber de antemano. Los scripts de degradación se escriben para revertir una migración completa. Esto los hace efectivamente inútiles, incluso para cambios no destructivos.
Mantenga la compatibilidad hacia atrás entre la base de datos y todas las versiones del código implementado actualmente en producción.
De esta manera una migración fallida no es un desastre. La versión anterior de la aplicación aún es compatible con la base de datos, por lo que simplemente puede revertir el código de la aplicación, investigar y tomar medidas correctivas.
Una solución mucho mejor es una estrategia de copia de seguridad y restauración adecuada y bien probada.
Es independiente de la estructura de la base de datos, y una vez que se prueba y se prueba que funciona, ningún script de migración puede romperla. Para un rendimiento óptimo, y si su infraestructura lo admite, le recomendamos que utilice la tecnología de instantáneas de su solución de almacenamiento subyacente . ¡Especialmente para volúmenes de datos más grandes, esto puede ser varios órdenes de magnitud más rápido que las copias de seguridad y restauraciones tradicionales!
Esto es compatible desde Flyway 5.0. Lamentablemente es una característica sólo comercial sin embargo.
He encontrado que la mejor manera de hacerlo es simplemente limpiar la base de datos y migrar a la versión específica a la que quería volver.
Como las preguntas frecuentes sugieren que los scripts de reversión son agradables en teoría, pero algunas migraciones simplemente no se pueden revertir. (Por ejemplo, si se elimina una tabla, restaurar la tabla DDL es fácil, pero la restauración de los datos que contiene puede ser difícil).
Supongo que necesita una estrategia de reversión cuando, por ejemplo, un socio falla en la etapa de producción y su implementación es esencial para su lanzamiento.
Podrías nombrar tus scripts de SQL de vuelo como estos:
V <YourReleaseNumber> .000_ <descripción> .sql
Ahora te puedes ir
V <YourReleaseNumber> .998_rollback.sql para revertir
y haga V <YourReleaseNumber> .999_reenroll.sql para volver a inscribirse.
En su entorno de CI / CD necesita 2 trabajos más (activados manualmente) después de su trabajo de implementación. Una para la reversión, que ejecuta el proceso de reversión, incluida la migración de la ruta migratoria. Otro para reinscribirse.
Solo tienes que cuidar la configuración de destino en la ruta migratoria.
Para su trabajo de implementación, su objetivo debe ser <YourReleaseNumber> .997
Para su trabajo de reversión <YourReleaseNumber> .998
Cuando inicie una nueva versión, asegúrese de no ejecutar el script rollback / reenroll de la versión anterior.
Como se dijo antes, una solución bien probada, copia de seguridad y restauración es la solución recomendada.
(sry por mal inglés)