我们使用Flyway迁移数据库模式,我们已经有超过100个迁移脚本.
一旦我们将多个迁移"压缩"到单个第一版迁移中,这在开发期间就可以了,因为我们删除并重新创建模式.但是在生产中这不起作用,因为Flyway无法验证迁移.
在这种情况下,我找不到任何文档或最佳做法.问题是文件数量不断增加,我不希望每次都看到数千个迁移文件,基本上如果生产已经是最新版本.我的意思是,版本号低于生产版本的迁移脚本与我们无关,如果我们可以将这些文件压缩到单个迁移中,那将是非常棒的.
我们正在使用MySQL.
我们该如何处理?
Dav*_*son 16
这不是重新基线会做什么的吗?
我还是飞路新手,但这就是我认为它会起作用的方式.在接受我的说法之前,请先测试以下内容.
删除schema_version表.删除迁移脚本.
运行flyway基线(这会重新创建schema_version表并将基线记录添加为版本1)
现在你很高兴.请记住,由于您已删除所有迁移脚本,因此无法"迁移"到任何先前版本,但这对您来说可能不是问题.
一步一步的解决方案:
drop table schema_version;V1__Baseline.sqlV1__Baseline.sql到脚本文件夹,因此它是Flyway唯一可用的脚本我们这样做是为了允许我们在开发环境中压缩用于构建新数据库的脚本,但也可以针对现有的生产数据库运行,而无需登录和删除 flyway_version_history 表,我们可以保留脚本(主要用于参考):
将所有脚本压缩为新脚本,例如将 V1 到 V42 压缩为新脚本 V43。通过将 .txt 放在末尾将 V1 到 V42 转换为文本文件。
将基线设置为 43。设置 flyway 以忽略丢失的迁移。
在脚本 V43 中,使用“if”块来保护创建/插入语句,以便它们不会为现有的生产数据库运行。我们使用 postgres 所以它是这样的:
DO $$
DECLARE
flywayVersion INTEGER;
BEGIN
SELECT coalesce(max(installed_rank), 0) INTO flywayVersion FROM flyway_schema_history;
RAISE NOTICE 'flywayVersion = %', flywayVersion;
IF flywayVersion = 0 THEN
RAISE NOTICE 'Creating the DB from scratch';
CREATE TABLE...
.....
END IF;
END$$;
Run Code Online (Sandbox Code Playgroud)
flyway 命令看起来像这样:
Flyway.configure()
.dataSource(...)
.baselineVersion("43")
.ignoreMissingMigrations(true)
.load()
.migrate()
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
2843 次 |
| 最近记录: |