关于Java：如何使用Flyway回滚迁移？

How to roll back migrations using Flyway?

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

一种用于向前迁移一个版本

一个用于迁移回一个版本

如何使用Flyway回滚版本？

尽管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.

相关讨论

最好的选择当然是使用适当支持DDL事务的数据库，例如PostgreSQL。这样，数据库将为您清理混乱。
您误解了我的问题。我不是说我想在交易过程中回滚以防失败。我是说客户有数据库的第4版，我想将其回滚到版本2。
一个人想要在生产系统上回滚多个成功迁移的现实用例是什么？
我当时正在考虑将开发人员数据库回滚到客户拥有的旧版本。尽管显然使用备份/还原是一种更好的方法(假设数据库不是太大)。
另一个用例是当新功能出现问题时回滚(生命)系统
多年来，我们一直在使用liquibase和postgresql，而无需回滚单个迁移。我们将切换到flyway，因为我们可以将迁移脚本放入不同的模块中。 Flyway只是在类路径中扫描迁移脚本。没关系。
请将关键点添加到您的帖子中，以便在链接断开时此答案仍然有用。这里的帖子需要独立存在，并带有指向补充信息的链接。
@Kevin：完成。我将"常见问题解答"部分复制到了答案中。
另一个用例是在进行某些迁移之前的分支上工作时。然后我想在其他分支上工作。必须回滚这些迁移，否则代码将被破坏。
@Gili对于开发人员部署旧版本数据库的问题，更好的解决方案是从头开始部署它。放下开发人员的副本，从零开始部署。如果您具有良好的CI设置(并且Flyway之类的技术的全部要点就是要帮助您将数据库整合为一体)，那么签出版本2的代码并运行部署脚本就很简单了。修正版本2可能仍然需要分支该代码。
@mirelon我将PostgreSQL数据库放在Docker容器中，并且为了回滚，我只是删除了该容器并基于一个基本映像启动了一个新容器，该基本映像包含一个稍低版本的数据库+一些测试数据。然后，我的应用程序会将这个新的数据库容器前滚到我签出的任何分支。 —切换到Flyway + Docker之后，我从未感到过任何向下迁移的必要:-)
我喜欢Flyway进行迁移，但是我发现不实施回滚的理由非常la脚。如@mirelon之前所述，在某些实际情况下回滚是必须具备的。
@ joaqunL.Robles当jpmc26用替代方法回答mirelons评论时，我认为它不是"必须具备的"。从头开始部署一个空数据库，并运行所有从0到所需停止点的正向迁移。这至少与使用向后迁移一样有效，因为它更容易保证其可再现性。
我已经使用Rails多年了，并且发现回滚迁移的功能对开发非常有帮助。尤其是在编写迁移过程中，您可能会发现自己忘记了一些关键更改，因此回滚，修改迁移并重新运行它要干净得多。当然，不应该在生产中使用回滚，但是在开发中可以节省大量时间，并且减少了迁移的过程。
@mockaroodev您可以将Flyway配置为在验证错误时自动清除数据库(例如，在更新现有迁移文件时)。是的，您丢失了数据，但是在开发中这几乎不是问题。
这个答案在技术上不再准确。 Flyway 5.0增加了对回滚的支持，但它仅具有商业功能。请参阅下面的帖子。

从Flyway 5.0开始支持。可悲的是，这只是商业用途。

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