问题描述
自成立以来，我们的主要项目一直在使用现在非常古老的Flyway版本。 （v3.2.1）
- 多年来，Flyway进行了大量改进，而v6 +似乎包含了我们MysqL模式的许多有趣功能。
- 尝试使用受支持的升级路径时，遇到了一些问题-例如我们的.sql迁移拒绝从头到尾进行迁移； Flyway v3.2.1认为我们所有的sql迁移都是有效的，但v4 +扼制了某些奇怪的注释语法。自然，要使迁移工作的文件修复程序将产生不同的校验和，这是安全升级的障碍。我很清楚v5中架构表名称的更改；这不是无法克服的。
- 我还在关注Liquibase与在线模式迁移工具； FB，Percona和GitHub的OST（gh-ost）看起来很有趣，但是我们使用外键，并且我们需要更多的副本，因此现在可能不在我们的视野中。
目前，我对带有Flyway v7 beta或切换工具的新基准感兴趣。如果您在k8上部署SaaS并有任何一般性建议，我会接受，但是我对一件事特别感兴趣：
人们如何克服较新版本的Flyway不再接受现有sql迁移的问题。或者，是否有人“放弃”并只是创建了新的基准，而不是进行漫长的升级？ （或从Flyway切换到具有类似优点的其他工具）
解决方法
这里至少有两个问题，有很多活动部件：
- 处理工具的约束，以及如何处理 Flyway 3->7+（遵循工具的文档）
- 一般情况下如何合并大型生产 SQL 迁移，这是一个过于笼统的问题，无法在此涵盖。
如果有人对第一个有更好（不太一般）的建议，我很乐意听到。
回复：第二，我们希望通过现成工具进行基础设施和部署。
我参与过的大多数项目都是基于 Spring 的。 （大型生态系统，即使没有 k8s 位）