如何处理无效的先前有效的 Flyway 迁移

Question

我有一个 Spring Boot 应用程序，它使用 Flyway 在 Postgres 中进行数据库迁移。

现在大约 4 岁了，所以我们说的是 Flyway 4.0.3、Spring Boot 1.3.x 和 Postgres 9.x。版本可能会升级，但我想在此之前修复任何现有问题。

与此同时，Postgres 已升级到高于 9.x 的版本。不幸的是，一些现有的迁移已经过时，因为它们包含不推荐使用的语法。因此，现在使用新数据库（即在开发环境中）启动应用程序会导致这些迁移失败。在生产中这很好，因为这些迁移已经应用并且不会再次应用。

我很好奇在这方面的最佳做法是什么。我不能只修复现有迁移中的语法，因为这会导致生产环境中的校验和失败。我知道repair 是一个东西，但是我不确定它是如何工作的以及如何将它与 Spring Boot 一起使用。

失败的 SQL：

UPDATE config
SET (description) = 'my description'
WHERE ...

正确的 SQL：

UPDATE config
SET description = 'my description'
WHERE ...

错误：

Message    : ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression

编辑 2020 年 4 月 24 日 Spring Boot 解决方案：

Grant Fitchey 在下面发布了关于如何使用 repair 的正确答案后，我将具体说明我是如何使用 Spring Boot 做到这一点的。我刚刚创建了一个 FlywayMigrationStrategy 的 bean，它调用 repair 在它调用 migrate 之前：

@Bean
public FlywayMigrationStrategy cleanMigrateStrategy() {
    return flyway -> {
        flyway.repair();
        flyway.migrate();
    };
}

将其部署到生产环境时，在启动期间，Postgres 中 schema_versions 表中的校验和已修复。在另一个版本中，我将再次删除 flyway.repair(); 行，否则显然这会产生应用无效迁移的风险。

Answer 1

您正在寻找修复选项。我不知道如何通过spring boot直接调用它，但是documentation is here。这应该完全符合您的要求。

因此，在这种情况下，第一步是修复迁移，以便它们在开发环境中正确执行。现在开发应该没问题了，flyway 应该可以成功迁移了。

在生产环境中，您现在应该会收到验证错误，因为校验和不同。 Flyway repair 将“修复”模式历史表，以便它存储的校验和与磁盘上的新校验和匹配，因此 flyway 验证再次通过。 具体来说，flyway repair 所做的是使模式历史记录表与您在磁盘上的内容相匹配。它将应用迁移的所有校验和更新为磁盘上的校验和（因此，只有在您确信更改相同时才使用它）。它还会从表中删除所有失败的迁移条目（同样，只有在您自己清理数据库后才使用它）。