我看过关于FlyWay处理多个数据库的帖子,但它们似乎都是独立的数据库。据我了解,FlyWay每个实例只能处理一个数据库,因此创建/清理数据库模式是完全独立的。
Multiple datasources migrations using Flyway in a Spring Boot application
我们的问题可能源于糟糕的数据库设计,但它就是这样,它不会很快改变。至于后台,这是一个带有MSSql DB的C#旧学校应用程序,我们目前只是使用FlyWay命令行进行评估。
DB(s)设置如下。
我有一些示例,其中AppDB具有引用其他表的视图/过程/等。还有其他DB访问AppDB的情况(IE ArchiveDB存储过程将从AppDB中提取)。
由于不同数据库之间存在这种依赖关系,FlyWay是否可以按所需顺序处理迁移/清理?例如
如果我有这个脚本顺序
如何更好地处理它呢?
答案 0 :(得分:0)
这可能是一个棘手的问题,尤其是对于具有循环依赖关系的ArchiveDB。
我正在处理的项目上有类似的设置。它们实际上是Oracle数据库中的不同模式,但是我们选择为每个模式保留一个单独的schema_version表(尝试保持信息显示可管理)。我们使用的方法是以依赖关系的主要顺序对我们的目录进行编号,并确保我们按该顺序应用。你的可能是:
10_AppDB
20_AppLogDB
30_AppAuditDB
40_AppArchiveDB
循环依赖关系是一项更多的工作,以确保它们可以正确地应用于干净的环境。幸运的是,我们没有遇到过这种情况,但未来可能会发生变化。我建议的方法是错开部署(使用migrate上的目标选项/属性),以便以必要的顺序创建对象。然后,当在新环境中从头开始创建时,您需要跨所有数据库应用于第一个合并点,然后将所有数据库应用于下一个数据库,依此类推。以你的榜样为基础:
# run flyway -target 2 for all DBs
10_AppDB___/V1__AppDB_Create_table
20_AppLogDB/V2__ArchiveDB_Create_table
# run flyway -target 4 for all DBs
10_AppDB___/V3__AppDB_Create_proc_pointing_to_ArchiveDB
20_AppLogDB/V4__ArchiveDB_Create_proc_pointing_to_AppDb