我们通过 Java API 对 MySQL 5.6（不支持事务 DDL）使用 Flyway 4。我们偶尔会遇到迁移失败的情况，有时是逻辑错误，有时是因为有人弄乱了数据库并且事情没有处于正确的状态。
所以我想知道，在这种情况下，我们是否应该从 schema_version 中删除行并让迁移重新运行，或者修复迁移或修复数据库？我们通常在迁移之前运行修复以修复任何失败的迁移，然后添加一个新的。
另请参阅：Should I be worried about creating idempotent migrations while using Flyway?
【问题讨论】：
标签： flyway
过去几年我一直在使用 Flyway 3，最近刚刚升级到 4。到目前为止，它已成功管理了大约 30 个左右不同的项目，并且非常适合交付管道。
在那两年里，我们确实经历了几次迁移，这些迁移是从我们希望从历史中消除的开发人员机器中实现的。在这些情况下，从schema_version 中删除一行通常是答案——它比repair 更快、更少的过程密集并且在我们的情况下风险更小。话虽如此，它只在开发/测试环境中实现过——所以一直存在一个非生产环境，它只接收工作迁移，没有失败/不希望的迁移。
我们的目标是让失败的迁移成为构建时间问题。因此，迁移版本得到验证，迁移本身被执行，并且组件针对该迁移的数据库运行，作为组件构建的一部分。我想说这在很大程度上导致了我们在处理如此大量的迁移管理项目时很少遇到的问题。
不记得我在哪里读过它，如果它是在 Flyway 的上下文中，但它类似于The price we pay for this kind of automation is discipline - 所以听到诸如“有人手动处理数据库”之类的东西肯定是对我来说是危险信号。
结论...
我认为减少失败的机会是关键。但是，当失败确实发生时，将您的策略定义为满足可接受的风险水平是您能做的最好的事情 - repair 和删除 schema_version 都有其缺点。
【讨论】：
repair 在应用的校验和中是不分青红皂白的，它将重新调整到可用的内容。这可能会造成您repairing 比您想象的要多的情况（例如，如果另一个迁移发生了变化）。基本上，您选择退出 validate 为您提供的所有保护。