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

Question

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

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

在Liquibase中，您将修复原始更改集并使用<validChecksum>标记通知Liquibase更改是按目的进行的。在Flyway中是否有<validChecksum>的吊坠，或实现相同的替代机制？

Answer 1

根据乱七八糟的大小你也可以

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

Answer 2

如果已经达到生产状态，隐藏这个糟糕变化的意义何在？每次在空数据库上重放都很昂贵（我假设CI运行）？使用该迁移创建新的数据库基准。

Answer 3

尽管这违反了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命令不同，它的优点是仅针对特定的迁移。