0

我们的主要项目从一开始就一直使用现在非常古老的 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 切换到另一个具有类似优点的工具）

4

1 回答 1

0

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

  1. 处理工具的约束，以及如何处理 Flyway 3->7+（按照工具的文档）
  2. 通常如何合并大型 prod SQL 迁移，这是一个太笼统的问题，无法在此处讨论。

如果有人对第一个有更好（不那么笼统）的建议，我很想听听。

回复：第二，我们正在从现成的工具中寻找我们的基础设施和部署。

我从事的大多数项目都是基于 Spring 的。（大型生态系统，即使没有 k8s 位）

于 2021-03-19T22:40:48.367 回答