MyBatis 迁移将每个 SQL 文件分成两部分:
- 一个用于向前迁移一个版本
- 一个用于迁移回一个版本
如何使用Flyway回滚版本?
虽然 Flyway 支持回滚(仅作为商业功能),但不鼓励使用它:
https://flywaydb.org/documentation/command/undo
虽然撤消迁移的想法很好,但不幸的是它在实践中有时会失败。一旦发生破坏性更改(删除、删除、截断……),您就会开始陷入麻烦。即使您不这样做,您最终也会创建用于恢复备份的自制替代方案,这些替代方案也需要进行适当的测试。
撤消迁移假定整个迁移成功,现在应该撤消。这对于在没有 DDL 事务的数据库上失败的版本化迁移没有帮助。为什么?迁移可能随时失败。如果您有 10 条语句,则第 1 条、第 5 条、第 7 条或第 10 条可能会失败。根本没有办法提前知道。相反,撤消迁移是为了撤消整个版本化迁移而编写的,在这种情况下无济于事。
我们认为更可取的另一种方法是保持数据库与当前部署在生产中的所有代码版本之间的向后兼容性。这样,失败的迁移就不是灾难。旧版本的应用程序仍然与数据库兼容,因此您可以简单地回滚应用程序代码,调查并采取纠正措施。
这应该辅以适当的、经过良好测试的备份和恢复策略。它独立于数据库结构,一旦经过测试并证明可以工作,任何迁移脚本都无法破坏它。为获得最佳性能,如果您的基础架构支持这一点,我们建议您使用底层存储解决方案的快照技术。特别是对于较大的数据量,这可能比传统的备份和恢复快几个数量级。
从 Flyway 5.0 开始支持此功能。可悲的是,它只是一个商业功能。
我假设您需要一个回滚策略,例如当合作伙伴在生产阶段失败并且他的部署对于您的发布至关重要。
您可以将 flyway SQL 脚本命名为:
V< YourReleaseNumber >.000_< description >.sql
现在您可以保留
V< YourReleaseNumber >.998_rollback.sql进行回滚
,并使V< YourReleaseNumber >.999_reenroll.sql重新注册。
在您的 CI/CD 环境中,您在部署作业之后还需要 2 个作业(手动触发)。一种用于回滚,它运行包括飞路迁移在内的回滚过程。其他用于重新注册。
您只需要关心 flyway 中的目标配置。
对于您的部署作业,您的目标应该是 < YourReleaseNumber >.997
对于您的回滚作业 < YourReleaseNumber >.998
当您开始一个新版本时,请确保您不会运行旧版本的回滚/重新注册脚本。
如前所述,推荐的解决方案是备份和恢复策略。
(抱歉英语不好)