FlyWay 与相互依赖的数据库

Question

我看过有关 FlyWay 处理多个数据库的帖子，但这一切似乎都是针对独立数据库的。据我了解，FlyWay 每个实例只能处理一个数据库，因此创建/清理数据库模式是完全独立的。

Multiple datasources migrations using Flyway in a Spring Boot application

我们的问题可能源于糟糕的数据库设计，但它就是这样，不会很快改变。至于背景，这是一个带有 MSSql DB 的 C# 老式应用程序，我们目前只是使用 FlyWay 命令行进行评估。

数据库是这样设置的。

• 应用数据库
• AppLogDB
• AppAuditDB
• AppArchiveDB
• ...

我有一些示例，其中 AppDB 具有引用其他表的视图/过程/等。也有其他 DB 访问 AppDB 的情况（IE ArchiveDB 存储过程会从 AppDB 拉取）。

由于不同数据库之间存在这种依赖关系，FlyWay 是否可以按所需顺序处理迁移/清理？例如

如果我有这个脚本顺序

• 应用数据库
  1. V1__Create_table
  2. V2__Create_proc_pointing_to_ArchiveDB
• 存档数据库
  1. V1__Create_table
  2. V2__Create_proc_pointing_to_AppDb

如何重新做以更像这样处理它

• AppDB、ArchiveDB
  1. V1__AppDB_Create_table
  2. V2__ArchiveDB_Create_table
  3. V3__AppDB_Create_proc_pointing_to_ArchiveDB
  4. V4__ArchiveDB_Create_proc_pointing_to_AppDb

Answer 1

这可能是一个棘手的问题，尤其是对于具有循环依赖关系的 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