1. 前言
随着项目的不断迭代,数据库表结构、数据都在发生着变化。甚至有的业务在多环境版本并行运行。数据为王的时代,管理好数据库的版本也成为了迫切的需要。如何能做到像 Git 之类的版本控制工具来管理数据库? Java 项目中常用 Flyway 和 Liquibase 来管理数据库版本。其中 Flyway 相对来说比较受欢迎。
2. Flyway 的特点
Flyway 大受欢迎是因为它具有以下优点:
- 简单 非常容易安装和学习,同时迁移的方式也很容易被开发者接受。
- 专一 Flyway 专注于搞数据库迁移、版本控制而并没有其它副作用。
- 强大 专为连续交付而设计。让Flyway在应用程序启动时迁移数据库。
3. Flyway 的工作机制
Flyway
需要在
DB
中先创建一个
metadata
表 (缺省表名为
flyway_schema_history
), 在该表中保存着每次
migration
(迁移)的记录, 记录包含
migration
脚本的版本号和
SQL
脚本的
checksum
值。下图表示了多个数据库版本。
对应的
metadata
表记录:
installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
---|---|---|---|---|---|---|---|---|---|
1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 2016-02-04 22:23:00.0 | 546 | true |
2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
Flyway
扫描文件系统或应用程序的类路径读取
DDL
和
DML
以进行迁移。根据
metadata
表进行检查迁移。
如果脚本声明的版本号小于或等于标记为当前版本的版本号之一,将忽略它们。其余迁移是待处理迁移:可用,但未应用。最后按版本号对它们进行排序并按顺序执行 并将执行结果写入 metadata 表。
对应的
metadata
表记录:
installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
---|---|---|---|---|---|---|---|---|---|
1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 2016-02-04 22:23:00.0 | 546 | true |
2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
3 | 2.1 | Refactoring | JDBC | V2_1__Refactoring | axel | 2016-02-10 | 17:45:05.4 | 251 | true |
Flyway 支持命令行(需要下载命令行工具)和 Java Api ,也支持构建工具 Maven 和 Gradle 。这里我们将目光放在 Java Api 上。
3. Flyway 的规则
Flyway 是如何比较两个 SQL 文件的先后顺序呢?它采用 采用左对齐原则, 缺位用 0 代替 。举几个例子:
1.0.1.1 比 1.0.1 版本高。
1.0.10 比 1.0.9.4 版本高。
1.0.10 和 1.0.010 版本号一样高, 每个版本号部分的前导 0 会被忽略。
Flyway 将 SQL 文件分为 Versioned 、 Repeatable 和 Undo 三种:
- Versioned 用于版本升级, 每个版本有唯一的版本号并只能执行一次.
-
Repeatable
可重复执行, 当
Flyway
检测到
Repeatable
类型的
SQL
脚本的
checksum
有变动, Flyway 就会重新应用该脚本. 它并不用于版本更新, 这类的migration
总是在 Versioned 执行之后才被执行。 - Undo 用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴,过于机械化,一般不推荐使用。一般建议使用 Versioned 模式来解决。
这三种的命名规则如下图:
-
Prefix
可配置,前缀标识,默认值
V
表示 Versioned ,R
表示 Repeatable ,U
表示 Undo -
Version
标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点
.
或下划线_
-
Separator
可配置, 用于分隔版本标识与描述信息, 默认为两个下划线
__
-
Description
描述信息, 文字之间可以用下划线
_
或空格 -
Suffix
可配置, 后续标识, 默认为
.sql
4. Spring Boot 集成 Flyway
Spring Boot 提供了对 Flyway 的自动配置 。使我们可以开箱即用 Flyway 进行数据库版本控制。
4.1 Flyway 依赖
你只需要引入依赖:
<!-- 无需版本号 -->
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>
复制代码
当然你要集成你的相关数据库环境。这里我们采用 H2 数据库来演示,其它数据库同理只不过方言不同。不熟悉 H2 数据库的可参阅我的专题文章 Spring Boot 2 实战:H2数据库集成以及使用 。
4.2 Flyway 配置
为了直观的讲解配置,首先在
Spring Boot
配置文件
application.yml
我们配置
H2
数据库为: