如何使用Flyway回滚迁移？ [英] How to roll back migrations using Flyway?
问题描述
MyBatis迁移将每个SQL文件分成两部分：
- 一个用于向前迁移一个版本
- 一个用于迁移回版本
如何使用 Flyway ？
在常见问题：
降级脚本/向下迁移？
Flyway不支持降级脚本。
脚本（由Rails Migrations推广）在理论上是一个不错的，不幸的是它在实践中崩溃了。一旦你有破坏性的改变（删除，删除，截断，...），你开始陷入麻烦。即使你没有，你最终会创建自制的备份来恢复备份，这也需要进行正确的测试。
迁移可能会失败，因为迁移失败。
保持数据库和当前在生产环境中部署的所有代码版本之间的向后兼容性。
这样，失败的迁移不是灾难。旧版本的应用程序仍然与DB兼容，因此您可以简单地回滚应用程序代码，调查并采取纠正措施。
更好的解决方案是一个正确的，经过良好测试的备份和恢复策略。
它独立于数据库结构，一旦测试并证明可以工作，没有迁移脚本可以打破它。为了获得最佳效果，如果您的基础设施支持此功能，我们建议您使用底层存储解决方案的快照技术。特别是对于更大的数据量，这可以比传统的备份和恢复更快几个数量级！
MyBatis migrations splits each SQL file into two sections:
- One for migrating forward one version
- One for migrating back one version
How does one roll back versions using Flyway?
Found the answer in the FAQ:
What about downgrade scripts/downward migrations?
Flyway does NOT support downgrade scripts.
While the idea of downgrade scripts (popularized by Rails Migrations) is a nice one in theory, unfortunately it 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.
Downgrade scripts assume the whole migration failed.
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. Downgrade scripts are written to roll back an entire migration. This renders them effectively useless, even for non-destructive changes.
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.
A much better solution is 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!
这篇关于如何使用Flyway回滚迁移？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
