最佳实践:使用后如何修改flyway迁移脚本

Posted

技术标签:

【中文标题】最佳实践:使用后如何修改flyway迁移脚本【英文标题】:Best practice: How to modify flyway migration script after it has been used 【发布时间】:2016-05-31 01:37:40 【问题描述】:

我正在寻找以下案例的建议。

我在生产环境中设置了 flyway 迁移脚本。在每次部署时,数据库都会迁移到当前版本。 我已经创建了几个已应用于生产数据库的迁移脚本。

最近我升级了我的开发 mysql 工具,其中包括关于使用已弃用函数的警告和其他警告。这些警告未在旧版本中显示。 当然,我想修复这些警告,尤其是在未来版本的数据库不再支持已弃用功能的情况下。 但是包含警告的迁移已经部署和使用。如果我更改其中一个脚本,则会出现飞行警告:

ERROR: Validate failed. Migration Checksum mismatch for migration 2.0
-> Applied to database : 1778293504
-> Resolved locally    : 1831545539

我可以更改存储在数据库中的校验和以进行迁移,但这听起来不是一个“好”的方法。 它已经被使用之后更改迁移脚本的常用方法/最佳实践是什么?

【问题讨论】:

【参考方案1】:

第一条规则是不要。

第二个是非常小心地使用 Flyway.repair() 将数据库中的校验和与磁盘上的校验和重新对齐。

【讨论】:

好的,这就是我的预期:D 感谢您的时间和“repair()”的提示! 我们在更新 db 后遇到了同样的问题 - 新版本与一些旧脚本不兼容(旧脚本有未引用的关键字,这对于旧版本的 db 可以,但对于新版本则不行)。解决方案是使用飞路修复。【参考方案2】:

我完全同意你不应该这样做的事实。

但如果您确实需要,您可以更改 flyway 配置并将 validateOnMigrate 布尔值设置为 false。

这是链接:https://flywaydb.org/documentation/commandline/migrate#validateOnMigrate

【讨论】:

以上是关于最佳实践:使用后如何修改flyway迁移脚本的主要内容,如果未能解决你的问题,请参考以下文章

实战Flyway迁移指南最佳实践

迁移到微服务时的最佳实践

SVN 布局——最佳实践

使用 Flyway 迁移创建用户

Django 最佳实践——迁移数据

JSON数据从OSS迁移到MaxCompute最佳实践