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

Question

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

假设在生产中部署后发现迁移

X

包含错误。回想起来，

X

本不应该按原样执行，但已经太晚了。但是，我们希望将迁移

X

替换为固定版本

X'

，这样从头开始填充的数据库就不会遇到相同的错误。

在 Liquibase 中，您可以修复原始变更集并使用

<validChecksum>

标签通知 Liquibase 该更改是有意进行的。 Flyway 中是否有

<validChecksum>

的挂件，或者实现相同功能的替代机制？

Answer 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

命令不同，它的优点是仅针对一个特定迁移。

Answer 2

取决于混乱有多大，你也可以

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

Answer 3

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

Answer 4

1 - 在数据库中手动更改

2 - 使用这些更改编写迁移

3 - 奔跑

flyway:repair -Dflyway.url=db_url -Dflyway.user=db_user -Dflyway.password=db_pass

4 - 测试 Flyway 是否会在空数据库上构建您假设的模式