【发布时间】：2021-01-03 14:35:14
【问题描述】：
我们的主要项目从一开始就一直使用现在非常古老的 Flyway 版本。 (v3.2.1)
- Flyway 多年来进行了大量改进，v6+ 似乎包含许多适用于我们的 MySQL 架构的有趣功能。
- 尝试支持的升级路径时，我遇到了一些问题 - 例如。我们的 .sql 迁移从头到尾拒绝迁移； Flyway v3.2.1 认为我们所有的 SQL 迁移都是有效的，但 v4+ 会因一些奇怪的注释语法而窒息。自然地，文件修复以使迁移工作会产生不同的校验和，这是安全升级的障碍。我很清楚 v5 中的模式表名称更改；这不是不可克服的。
- 我也在关注 Liquibase 与在线模式迁移工具； FB、Percona 和 GitHub 的 OST (gh-ost) 看起来很有趣，但我们使用了外键，而且我们需要更多的副本，所以我们现在可能无法做到这一点。
目前，我对带有 Flyway v7 测试版或切换工具的新基线感兴趣。如果您在 k8s 上部署 SaaS 并有任何一般性建议 - 我会接受，但我对一件事特别感兴趣：
人们如何克服新版本的 Flyway 不再接受现有 SQL 迁移的问题。或者，有没有人“放弃”并刚刚创建了一个新的基线，而不是进行漫长的升级路径？ （或者，从 Flyway 切换到另一个具有类似优点的工具）
【问题讨论】：
-
您是否使用 SQL Server 以外的任何东西？如果是这样，那么像 liquibase 这样支持许多不同数据库平台的东西可以使用 liquibase generateChangelog 使跨平台迁移也更容易。
-
感谢您的回信。抱歉回复慢。 MySQL 是我们目前的系统，但我知道 postgres 和 Microsoft 的 SQL 也是很常见的变体。 Liquibase 非常有趣，我可能会在自己的项目中使用它，但我很好奇人们如何在 prod 中使用 k8s。具体来说：如果您没有任何数据库副本，何时运行 SQL 迁移？似乎新的或旧的 pod 总是在零停机情况下执行。这意味着每次迁移都必须向前或向后兼容，并且确实没有具有一般安全保证的滚动部署。暂时进入只读状态？
-
我意识到这是一个老问题......您可以在这里考虑蓝/绿部署策略。您使用 2 个数据库运行临时同步脚本以将新条目从旧数据库复制到新数据库（如果可能）。在这样做时，您可以滚动您的 Pod 以引用新的数据库服务器。迁移完成后，解散旧服务器。只是一个想法......
-
谢谢，伙计们。更新：我们构建了一个带有 k8s 作业的 Docker 映像来管理迁移，这也确保我们始终准确地知道我们在做什么以及什么时候做 w.r.t。架构改变。对于在线迁移，这是您需要超过某个成熟度阈值的东西，Percona 工具似乎是要走的路，一旦您达到约 10M 行或每个 DB 约 10G 表 + 索引。避免（或过多）FK 可能会使该建议发生波动——想象成千上万的蜜蜂在蜂巢上爬行，而蜂王则指挥交通。 （根据您的系统需求，您会知道 DDL 何时过慢）
标签： mysql database-migration liquibase flyway pt-online-schema-change