【问题标题】:Lazy DB migration using Flyway使用 Flyway 进行延迟数据库迁移
【发布时间】:2018-11-26 14:16:46
【问题描述】:

我们正在使用 Flyway 迁移我们的数据库,我们实际上有数千个模式(又名 Silos)。

当我们部署新构建时,即使软件构建不需要迁移,数据库迁移也可能需要 10 分钟。

我想知道我们是否可以配置 Flyway 进行惰性 DB 迁移:检查每个 schema_version 表中的所有模式,如果表中的最新 DB 版本等于当前软件构建的版本,则没有需要做任何事情;否则,如果软件生成器中的数据库版本较新,只需从表中的最新版本开始进行必要的迁移。

如果我们能做到以上几点,迁移时间可能会从 10 分钟缩短到几秒钟。

有人能说明如何做到这一点吗?谢谢!

【问题讨论】:

  • 我真的不明白这与 FlywayDB 所做的有什么不同:它会检查当前版本,并且只在需要时更新它。
  • @JBNizet 它可以做到这一点,但即使不需要做任何迁移工作,它也可以为数千个模式中的每一个模式做很多其他事情。我能够窥探我们的网络服务器和数据库之间的流量并看到它。我认为必须有一种方法可以使db迁移变得懒惰,如果不需要迁移,则什么都不做!

标签: java flyway


【解决方案1】:

正如 JB Nizet 所说,Flyway 会检查当前版本,除非需要,否则不会执行任何更新。

但是,如果您的目标是摆脱这种检查,因为这需要时间,您可能会切换到基于 Java 的迁移而不是基于 SQL 的迁移,因为与后者不同的是,Java 迁移没有校验和,而这您是否可以减少一些执行时间;不过仍然需要测试。

这件事来自官方文档:

与 SQL 迁移不同,Java 迁移默认情况下没有 校验和,因此不参与变化检测 Flyway 的验证。这可以通过实施 MigrationChecksumProvider 接口。

我不知道这是否会减少执行时间,但至少值得测试。

【讨论】:

  • 抱歉回复晚了。当有SQL迁移脚本列表时,是否可以配置flyway跳过验证(包括校验和验证)?
猜你喜欢
  • 1970-01-01
  • 2017-07-07
  • 2013-07-01
  • 2023-03-13
  • 2015-08-18
  • 2017-07-10
  • 2013-03-06
  • 2014-08-02
  • 2019-04-22
相关资源
最近更新 更多