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

flyway-logo.jpg

Flyway介绍

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

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

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

2018年度,产品被下载1千万多次:

flyway-download-stat.jpg

开源:

flyway-open-source.jpg

支持多种使用方式:

flyway-varias-client.jpg

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

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

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

支持多种数据库:

flyway-database-support.jpg

被spring-boot集成:

flyway-spring-boot-support.jpg

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

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

Flyway的工作模式

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

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

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

flyway-script-name.jpg

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

具体要求:

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

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

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

flyway-schema-history.jpg

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插件所支持的命令:

flyway-maven-support.jpg

使用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的配置。

flyway-config-datasource.jpg

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

flyway-config-locations.jpg

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

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

使用总结

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

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

方案一:

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

方案二:

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

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

推荐阅读更多精彩内容