Flyway升级与过渡到在线模式迁移等

Question

我们的主要项目自启动以来一直使用现在非常旧的 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 或切换工具的新基线感兴趣。如果您在 k8s 上部署 SaaS 并有任何通用建议——我会接受，但我对一件事特别感兴趣：

人们如何克服新版本的 Flyway 不再接受现有 SQL 迁移的问题。或者，是否有人“放弃”并只是创建一个新的基线，而不是进行漫长的升级路径？ （或者，从 Flyway 切换到另一个具有类似优点的工具）

Answer 1

您可以尝试一下 bytebase (bytebase.com)。

• 基于网络
• 开源
• 可以执行由 GitHub/GitLab 触发的具有完整历史记录的 MySQL 架构迁移

Answer 2

这里至少有两个问题，有很多移动部件：

1. 工具的限制，以及如何处理 Flyway 3->7+（遵循工具的文档）
2. 大型生产 SQL 迁移的最佳实践，这是一个过于普遍的问题，无法在此讨论。

如果有人对第一个有更好（不太笼统）的建议，我很想听听。关于第二个问题，我们正在寻找现成工具的基础设施和部署。我参与过的大多数项目都是基于 Spring 的。 （大型生态系统，即使没有 k8s 位）