flyway - 从 schema_version 中删除行是正确的做法吗？

Question

我们通过 Java API 使用 Flyway 4 针对 MySQL 5.6(不支持事务性 DDL)。我们很少遇到迁移失败的情况，有时是逻辑错误，有时是因为有人破坏了数据库，导致事情不在正确的状态。

所以我想知道，在这种情况下，我们是否应该从 schema_version 中删除行并让迁移重新运行，同时修复迁移或修复数据库？我们通常在迁移之前运行修复以修复任何失败的迁移，然后添加新的迁移。

另请参阅:Should I be worried about creating idempotent migrations while using Flyway?

Answer 1

过去几年我一直在使用 Flyway 3，最近才升级到 4。到目前为止，它已成功管理大约 30 个不同的项目，并且非常适合交付管道。

在那两年中，我们确实经历了几次迁移，这些迁移是从我们希望从历史中删除的开发人员机器中实现的。在这些情况下，从 schema_version 中删除一行通常是答案 - 它比 repair 更快，过程密集度更低在我们的情况下风险较小。话虽这么说，它只在开发/测试环境方面做到了 - 因此一直存在一个非生产环境，它只接收工作迁移而没有失败/不需要的迁移。

我们的目标绝对是让失败的迁移成为构建时的问题。因此，迁移版本得到验证，迁移本身被执行，组件针对迁移后的数据库运行，作为组件构建的一部分。我想说这在很大程度上导致了我们在处理如此大量的迁移管理项目时出现的罕见问题。

不记得我是在哪里读到它的，是否是在 Flyway 的上下文中读到的，但它与 The price we pay for this kind of automation is discipline 类似。 - 所以听到“有人手动处理数据库”之类的话对我来说绝对是一个危险信号。

总之……

我认为最大程度地减少失败的机会是关键。但是，当确实发生故障时，将您的策略​​定义为满足可接受的风险水平是您能做的最好的事情 - repair并删除 schema_version两者都有其缺点。