java如何使用Flyway回滚迁移？

Question

MyBatis迁移将每个SQL文件拆分为两个部分：

1. 一个用于向前迁移一个版本
2. 一个用于迁移回一个版本

如何使用Flyway回滚版本

Answer 1

我假设您需要回滚策略，例如，当合作伙伴在生产阶段失败，并且他的部署对您的发布至关重要时

您可以这样命名flyway SQL脚本：
V<；YourReleaseNumber>；。000_<；说明>；。sql

现在你可以离开了
V<；YourReleaseNumber>；。998_回滚。用于回滚的sql
使V<；YourReleaseNumber>；。999_重新开始。sql重新滚动

在CI/CD环境中，在部署作业之后，还需要另外两个作业（手动触发）。一个用于回滚，它运行包括flyway migrate在内的回滚过程。另一个是reenroll
你只需要注意flyway中的目标配置
对于部署工作，您的目标应该是<；YourReleaseNumber>；。997
为您的回滚工作<；YourReleaseNumber>；。998

启动新版本时，确保不会运行旧版本的回滚/重新回滚脚本

正如前面所说，经过充分测试的备份和恢复策略是推荐的解决方案

（sry代表糟糕的英语）

Answer 2

这是从Flyway 5.0开始支持的。遗憾的是，这只是一个商业功能

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

Answer 3

虽然Flyway支持回滚（仅作为商业功能），但不鼓励使用：

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

While the idea of undo migrations is nice, unfortunately it sometimes breaks down in practice. As soon as you have destructive changes (drop, delete, truncate, …), you start getting into trouble. And even if you don’t, you end up creating home-made alternatives for restoring backups, which need to be properly tested as well.

Undo migrations assume the whole migration succeeded and should now be undone. This does not help with failed versioned migrations on databases without DDL transactions. Why? A migration can fail at any point. If you have 10 statements, it is possible for the 1st, the 5th, the 7th or the 10th to fail. There is simply no way to know in advance. In contrast, undo migrations are written to undo an entire versioned migration and will not help under such conditions.

An alternative approach which we find preferable is to maintain backwards compatibility between the DB and all versions of the code currently deployed in production. This way a failed migration is not a disaster. The old version of the application is still compatible with the DB, so you can simply roll back the application code, investigate, and take corrective measures.

This should be complemented with a proper, well tested, backup and restore strategy. It is independent of the database structure, and once it is tested and proven to work, no migration script can break it. For optimal performance, and if your infrastructure supports this, we recommend using the snapshot technology of your underlying storage solution. Especially for larger data volumes, this can be several orders of magnitude faster than traditional backups and restores.