Liquibase数据库迁移,随着时间的推移进行管理

时间:2014-12-18 16:33:35

标签: database-migration liquibase

我们一直在使用Liquibase进行数据库迁移,这些迁移运行在Migrations.xml文件中。这引用了我们所有的迁移,因此它看起来具有以下效果:

<include file="ABC.xml" relativeToChangelogFile="true" />
<include file="DEF.xml" relativeToChangelogFile="true" />
<include file="HIJ.xml" relativeToChangelogFile="true" />
...

然而,随着时间的推移,这已经增长了很长时间。想要重构这个有没有人解决这个问题?有哪些方案可以基本上压缩所有这些?

由于

2 个答案:

答案 0 :(得分:3)

没有单一的答案,最有效的方法取决于您的环境,流程以及您想要削减它们的原因。

一般情况下,我建议让你的更新日志增长,因为现有的步骤是你测试,部署和知道的步骤是正确的。改变它们会带来风险,这总是很好的避免。保持更改日志不变也允许您继续以与旧实例相同的方式引导新的dev / QA数据库。

虽然对于拥有大量更改日志会有一些性能损失,但Liquibase会尝试将其保持在最低限度,主要是解析changelog文件,然后从DATABASECHANGELOG表中读取,该表应该可以很好地扩展。由于liquibase update通常很少运行,即使需要几秒钟才能运行它,通常也不是什么大问题。

所有这一切,有时候你的更新日志清楚了。最好的方法取决于您要解决的问题是什么。

最简单的方法通常是删除对最早的更改日志文件的包含引用。如果您知道所有数据库都已在ABC.xml和DEF.xml中应用了changesSets,您只需从主更改日志中删除对它们的引用即可。 Liquibase并不关心是否有&#34;未知&#34; DATABASECHANGELOG表中的changeSet。如果您想继续使用ABC.xml和DEF.xml来提升开发和QA环境,您可以创建第二个遗产&#34; master changelog.xml包含它们,并在需要时运行两个更改日志或确保旧版更改日志包含旧的和新的更改日志。

如果您不想完全删除changeLog引用,则可以手动修改现有的changeSet。通常,只有一些更改可以在更新性能方面产生重大影响。例如,如果创建了一个索引然后删除了索引,则可以通过删除drop并创建changeSet来跳过创建的开销。同样,liquibase并不关心已经运行changeSet的数据库,也不会为新的数据库看到它们。如果您有一些可能仍具有索引并且希望删除它的数据库,则可以在删除创建变更集后在drop changeSet上使用indexExists前置条件。

前置条件检查也很昂贵,尤其取决于数据库供应商。有时删除现在不需要的前置条件检查也可以提高性能。

答案 1 :(得分:0)

到目前为止,这对我们来说并不是一个问题。是的,你最终得到了很多包括但是到目前为止我根本就不在乎。我强烈建议不要删除任何旧的变更集或对它们进行更改。尽量保持一切可以复制。

根据应用程序的版本对变更集进行分组可能会有所帮助。我的意思是,在您的migrations.xml文件中包含应用程序的每个版本的文件,其中包括您的&#34; real&#34;变更。这样,您还可以轻松找出哪个变更集属于您的应用程序的哪个版本。