如何应对不断变化的 Flyway 迁移？

Posted 2023-03-14

【中文标题】如何应对不断变化的 Flyway 迁移？

【英文标题】：How to deal with changing Flyway migrations?

【发布时间】：2015-11-05 07:43:18

【问题描述】：

我目前正在调查Flyway 作为Liquibase 的替代品，但无法在文档中找到以下问题的答案：

假设迁移X 在生产部署后发现包含错误。回想起来，X 不应该按原样执行，但已经太迟了。但是，我们希望将迁移 X 替换为固定版本 X'，这样从头开始填充的数据库不会出现相同的错误。

在 Liquibase 中，您将修复原始变更集并使用 <validChecksum> 标签通知 Liquibase 该更改是有意进行的。 Flyway 中是否有 <validChecksum> 的挂件，或者实现相同的替代机制？

【参考方案1】：

虽然它违反了 Flyway 的 API，但以下方法对我们来说效果很好：

编写一个beforeValidate.sql 来修复校验和以匹配预期值，这样当 Flyway 实际验证校验和时，一切看起来都很好。

一个例子：

-- The script xyz/V03_201808230839__Faulty_migration.sql was modified to fix a critical bug.
-- However, at this point there were already production systems with the old migration file.
-- On these systems, no additional statements need to be executed to reflect the change,
-- BUT we need to repair the Flyway checksum to match the expected value during the 'validate' command.
UPDATE schema_version
SET checksum = -842223670
WHERE (version, checksum) = ('03.201808230839', -861395806);

与 Flyway 的 repair 命令不同，这样做的好处是只针对一个特定的迁移。

【参考方案2】：

如果它已经投入生产，隐藏这个糟糕的变化有什么意义？每次在空数据库上重播是否昂贵（我假设 CI 运行）？使用已包含该迁移的新数据库基线。

【参考方案3】：

根据你的混乱程度你也可以

只需进行后续迁移以更正它（新列名中的错字，..） 如果这不是一个选项，您必须手动修复迁移和数据库并发出 Flyway.repair() 以重新对齐校验和http://flywaydb.org/documentation/command/repair.html

【讨论】：

我知道repair 命令，但这只会禁用所有迁移的给定运行的任何校验和验证，对吧？我正在寻找修复单个变更集。