Flyway

官网：https://flywaydb.org/documentation/

Github: https://github.com/flyway/flyway

为什么要迁移数据库？

首先，让我们从头开始，假设我们有一个名为Shiny的项目，其主要可交付成果是一个名为Shiny Soft的软件，它连接到名为Shiny DB的数据库。

表示这一点的最简单图表可能如下所示：

我们有我们的软件和我们的数据库。伟大的。这很可能就是您所需要的。

但在大多数项目中，这种简单的世界观很快就会转化为：

我们现在不仅要处理我们环境的一个副本，而且还要处理几个。这带来了许多挑战。

我们一直很擅长在代码方面解决它们。

• 版本控制现在是通用的，每天都有更好的工具。
• 我们有可重复的构建和持续集成。
• 我们有明确定义的发布和部署流程。

但是数据库呢？

不幸的是，我们在那里做得并不好。许多项目仍然依赖于手动应用的 sql 脚本。有时甚至没有（这里或那里的快速 sql 语句来解决问题）。很快就会出现许多问题：

• 这台机器上的数据库处于什么状态？
• 此脚本是否已应用？
• 生产中的快速修复是否在之后的测试中应用？
• 你如何设置一个新的数据库实例？

这些问题的答案往往是：我们不知道。

数据库迁移是重新控制这一混乱局面的好方法。

它们允许您：

• 从头开始重新创建数据库
• 始终明确数据库处于什么状态
• 以确定的方式从当前版本的数据库迁移到新版本

Flyway 的工作原理

最简单的情况是当您将Flyway指向一个空数据库时。

它将尝试定位其模式历史表。由于数据库是空的，Flyway 不会找到它，而是会 创建它。

您现在有一个默认情况下包含一个名为flyway_schema_history 的空表的数据库：

该表将用于跟踪数据库的状态。

紧接着 Flyway 将开始扫描文件系统或应用程序的类路径以进行迁移。它们可以用 Sql 或 Java 编写。

然后根据版本号对迁移进行排序并按顺序应用：

随着每次迁移的应用，架构历史表会相应地更新：

有了元数据和初始状态，我们现在可以讨论迁移到更新版本。

Flyway 将再次扫描文件系统或应用程序的类路径以进行迁移。根据模式历史记录表检查迁移。如果它们的版本号低于或等于标记为当前的版本之一，它们将被忽略。

剩余的迁移是待处理的迁移：可用，但未应用。

然后它们按版本号排序并按顺序执行：

架构历史表会相应更新：

就是这样！每当需要发展数据库时，无论是结构 (DDL) 还是参考数据 (DML)，只需创建一个版本号高于当前版本号的新迁移即可。下次 Flyway 启动时，它会找到它并相应地升级数据库。

Springboot 中使用(Maven)

引入依赖

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>8.5.4</version>
</dependency>

<plugin>
	 <groupId>org.flywaydb</groupId>
	 <artifactId>flyway-maven-plugin</artifactId>
	 <version>8.5.4</version>
</plugin>

配置

spring:
  flyway:
    enabled: true
    encoding: UTF-8
    clean-disabled: true
    locations: classpath:db/migration
    # sql文件命名规范：V版本号__描述.sql，例：V1.0__init_db.sql
    sql-migration-prefix: V  # V代表版本迁移，U代表撤销迁移，R代表可重复迁移
    sql-migration-separator: __   # 分隔符：固定由两个下划线 __ 组成
    sql-migration-suffixes: .sql  # 后缀
    validate-on-migrate: true     # 执行迁移时是否自动调用验证
    baseline-on-migrate: true     # 迁移非空模式时是否自动调用基线

在resoures下 创建 db/migration

我们只需要将sql脚本放在 db/migration下，项目启动，即可自动同步数据库了