根据 Flyway，原始 SQL 脚本现在无效

Posted 2023-03-28

【中文标题】根据 Flyway，原始 SQL 脚本现在无效

【英文标题】：Original SQL script now invalid according to Flyway

【发布时间】：2021-11-03 07:18:47

【问题描述】：

我们有一个已经投入生产一段时间的 Spring Boot 应用程序。我们使用 Flyway 来管理数据库迁移。我刚刚从 2.4.5 升级到 Spring boot 2.5.4，随之升级到 Flyway 7.7.3。

在全新的本地环境中执行所有迁移时，迁移现在由于以下注释的语法问题而失败：

---*********************---
-- ** AUDITING TABLES ** --
---*********************---

我想这在已经执行此迁移的环境中不会成为问题，但是鉴于迁移时的校验和比较无法编辑原始文件，对于具有新数据库的新环境，解决此问题的最佳方法是什么?

我当前的版本控制只包括一个主要版本，即 V2、V3 等。我的想法是摆脱 V2（有问题的脚本）并引入 V2.1，这将是带有错误评论部分的 V2 的精确副本删除。然后我会将ignoreMissingMigrations 和ignoreIgnoredMigrations 都设置为true

这听起来像是解决这个问题的正确方法吗？

提前致谢。

【问题讨论】：

我应该提到我使用的是 mysql 5.7。初步测试表明我在 OP 中提到的方法似乎有效。除非有人提出更好的选择，否则很可能会坚持使用这种方法。

你的 sql 文件的编码字符集是什么？较低版本的 flyway 没有问题，但是您所有的 sql 文件都应该是 UTF-8 或 US7ASCII 或者如果它不同，您必须自己指定编码：flywaydb.org/documentation/configuration/parameters/encoding

【参考方案1】：

更改脚本然后执行 flyway repair 将是理想的解决方案 - 这将纠正校验和。

假设此选项由于某种原因不可用（如果我们可以修复它，知道它是什么会很有帮助！），以上听起来是正确的。 ignoreMissingMigrations 表示您的旧部署不会反对 V2 不存在，ignoreIgnoredMigrations 表示他们不会反对 V2.1 存在。缺点是这些忽略在长期内可能无效 - 例如，它们不会捕捉到后来无意丢失的脚本。

【讨论】：

谢谢@Julia。你可能是对的，flyway repair 是要走的路。我确实遇到过，但它似乎是更具侵入性的选择，并且不能 100% 确定潜在的副作用。我还没有部署到任何实时环境，所以我有时间恢复到那个选项。