Flyway：数据库版本迁移工具的介绍

目录

• Flyway介绍
• Flyway的工作模式
• Flyway的使用场景
  • 命令行
  • 使用Maven或Gradle插件
    • migrate
    • clean
    • info
    • validate
    • baseline
  • Java API
    • step1：在maven中引入flyway依赖
    • step2：配置application
    • step3：在指定的目录编写脚本
• 使用总结

Flyway介绍

Flyway的定位：数据库的版本控制。

用一种简单、干净的方案，帮助用户完成数据库迁移的工作。使用Flyway，用户可以从任意一个数据库版本迁移到最新版本，简单而且有效。

支持多个平台：windows、ios、linux、docker、java、android

2018年度，产品被下载1千万多次：

开源：

支持多种使用方式：

基于命令行模式，用户从官网下载工具包，进行一些必要的配置，就可以通过命令行使用其功能。

基于Java API，用户可以将Flyway提供的第三方包加入classpath，通过Flyway提供的API来使用其功能。

基于Maven或Gradle，用户可以通过配置插件，运行mvn或gradle命令来使用其功能。

支持多种数据库：

被spring-boot集成：

官方文档简洁，以我这样蹩脚的英语水平，也很容易理解。

P.S. 开源版本支持大部分常用的功能，Flyway还有商业版本，会支持一些额外的功能。

Flyway的工作模式

这一节主要介绍Flyway是如何工作的，也可以理解为flyway的数据库升级方案。

Flyway可以对数据库进行升级，从任意一个版本升级到最新的版本。但是升级的依据是用户自己编写的sql脚本，用户自己决定每一个版本的升级内容。

Flyway不限定脚本里面的内容，但是对脚本文件的名称有一定的要求：

版本号可以使用小版本，如V1.1。

具体要求：

• 版本号和版本描述之间，使用两个下划线分隔。
• 版本描述之间，使用一个下划线分隔单词。
• 版本号唯一：不允许多个脚本文件有相同的版本号。

使用Flyway升级，flyway会自动创建一张历史记录表：flyway_schema_history。

这张表记录了每一次升级的记录，包括已经执行了哪些脚本，脚本的文件名，内容校验和，执行的时间和结果：

flyway在升级数据库的时候，会检查已经执行过的版本对应的脚本是否发生变化，包括脚本文件名，以及脚本内容。如果flyway检测到发生了变化，则抛出错误，并终止升级。

如果已经执行过的脚本没有发生变化，flyway会跳过这些脚本，依次执行后续版本的脚本，并在记录表中插入对应的升级记录。

所以，flyway总是幂等的，而且可以支持跨版本的升级。

如果你好奇，flyway如何检查脚本文件的内容是否有修改。你可以注意以下记录表中有一个字段checksum，它记录了脚本文件的校验和。flyway通过比对文件的校验和来检测文件的内容是否变更。

使用上面的方式，升级一个空的数据库，或者在一直使用flyway升级方案的数据库上进行升级，都不会又问题。但是，如果在已有的数据库引入flyway，就需要一些额外的工作。

flyway检测数据库中是否有历史记录表，没有则代表是第一次升级。此时，flyway要求数据库是空的，并拒绝对数据库进行升级。

你可以设置baseline-on-migrate参数为true，flyway会自动将当前的数据库记录为V1版本，然后执行升级脚本。这也表示用户所准备的脚本中，V1版本的脚本会被跳过，只有V1之后的版本才会被执行。

下文在介绍Maven客户端的时候，会介绍另一种方案，实现在已有数据库中第一次引入flyway。

Flyway的使用场景

命令行

用户可以在官网下载适合自己平台的工具包，进行相关配置之后，就可以通过命令行的方式使用Flyway。

这一块只是在官网上看到其介绍，本人并没有尝试，我直接选择了后面的方案。

使用Maven或Gradle插件

这种方式可以代替命令行的方式，因为我们项目中就使用maven，所以我更倾向于使用这种方式。

以Maven为例，在pom文件中进行必要的配置，包括插件及插件所需要的一些数据库连接信息，就可以通过运行插件来使用其功能。

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    <properties>
        <flyway.user>postgres</flyway.user>
        <flyway.password>postgres</flyway.password>
        <flyway.url>jdbc:postgresql://localhost:5432/test?currentSchema=demo_flyway</flyway.url>
        <flyway.driver>org.postgresql.Driver</flyway.driver>
    </properties>

    <dependencies>
        ...
        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <scope>runtime</scope>
        </dependency>
        ...
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.flywaydb</groupId>
                <artifactId>flyway-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

maven插件所支持的命令：

使用maven命令执行插件，默认在classpath:/db/migration目录搜索脚本，如果该目录不存在，命令将被忽略。

所有的命令，以如下的格式执行：

mvn flyway:{flyway-command}

migrate

mvn flyway:migrate

这个命令会搜索默认的脚本目录，检测并根据结果选择执行升级脚本。

clean

mvn flyway:clean

这个命令会清除指定schema下所有的对象，包括table、view、triggers...，让schema变成空的状态。

info

mvn flyway:info

这个命令显示指定schema的升级状态，当前的数据库的版本信息。

validate

mvn flyway:validate

这个命令用于校验，范围包括已升级的脚本是否改名，已升级的脚本内容是否修改。所有针对已升级的脚本进行的改动都会导致校验失败。

执行migrate会自动进行校验，如果失败将不会做任何的migrate。

flyway希望用户提供的脚本是稳定的，以免造成额外的复杂性和混乱。

baseline

mvn flyway:baseline

如果用户从一个已有的数据库导出脚本，作为flyway的升级脚本。已存在的数据库是不需要升级的。

baseline用于将当前数据库标记为baseline，并记录version为1。这表示用户继续执行migrate命令时，会自动跳过V1版本对应的脚本。

而对于空的数据库，因为没有执行baseline，所以可以正常的执行V1版本对应的脚本。

P.S. 手动修改flyway自动生成的baseline记录，将版本号改为其他的版本号，将自动跳过该版本及更早的版本。

Java API

Flyway提供了基于Java的API包，用户可以将API包引入maven依赖，直接通过调用其API来执行相关命令。

Spring-Boot集成了Flyway，只要把API包加入classpath，spring-boot在启动应用时会去指定的目录查找脚本文件，并根据一定的策略选择或忽略执行。

使用Spring-Boot，用户不必再显式的编写代码调用API，只需要将脚本文件放在约定的目录，或者告诉Spring-Boot你把脚本文件放在哪里了。

如果用户需要实现非常灵活的迁移，Spring-Boot默认的方案无法满足，也可以尝试寻找自己编码调用API的方案。

以下内容介绍基于Spring-Boot + Maven的集成方案：

step1：在maven中引入flyway依赖

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ...
    <dependencies>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
        </dependency>

        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <scope>runtime</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
              ...
    </dependencies>
    ...
</project>

flyway-core即为我们所说的API包，除此之外，还要引入postgresql驱动包和spring-boot-starter-jdbc。

step2：配置application

按照常规的方式，在application.yml文件中配置spring.datasource系列：

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/test?currentSchema=demo_flyway
    driver-class-name: org.postgresql.Driver
    username: postgres
    password: postgres

spring为flyway准备了专属的数据源配置，但是在默认的情况下，可以直接使用spring.datasource的配置。

用户可以将脚本放在约定的位置：classpath:/db/migration，或者配置一个自定义的位置：

step3：在指定的目录编写脚本

如果用户没有特地设置脚本的位置，则应该在/db/migration创建脚本。否则，在对应的位置创建脚本。

使用总结

我们是在中途尝试使用flyway，所以开发环境会有一个已存在的数据库。我们需要从开发环境中导出数据库脚本，并对开发环境数据库进行baseline标记。导出的脚本可用于新环境的部署。

如果我们已经有了生产环境，而且生产环境和开发环境的数据库已经有了较大的差异。暂时可以想到的方案大概有2个方案：

方案一：

在生产环境备份数据库，然后创建一个全新的数据库，手动将备份库里的数据导入到新的数据库。

方案二：

基于生产环境的数据库，创建V1版本的脚本；基于开发库相对于生产库的变更，创建V2版本的脚本。在开发环境baseline，然后修改版本记录，改为2。在生产环境中baseline，然后migrate使其升级到2。

方案一，需要更多的人工介入，但是比较稳妥；方案二，难点在于溯源出正确的差异，编制V2脚本。