SpringBoot整合Flyway解决数据库版本控制问题 -清零世界

bubuko 2022/1/25 20:07:18 java 字数 7595 阅读 1638 0 来源 http://www.bubuko.com/infolist-5-1.html

写在前面

　　最近由于项目变更比较大，需要经常修改表结构，然后对应的测试，开发，生产环境数据库均要修改，有时候一不小心就忘记修改某个环境下的数据库了，

等出问题才发现表结构没有更新，如果项目还没上线，还可以把表删除了重新创建，但是如果项目已经上线了，就不能这样简单粗暴了，我们需要通过 SQL 脚本

在已有数据表的基础上进行升级。鉴于这种情况，于是决定寻找数据库版本控制工具。

在Java这部分，对数据库版本控制的主要有两个工具：

Flyway
Liquibase

两个工具各有千秋，但是核心功能都是数据库的版本管理，这里主要来看 Flyway。就像我们使用 Git 来管理代码版本一样，Flyway 可以用来管理数据库版本。

Flyway官网地址：https://flywaydb.org

技术分享图片

1、Flyway是如何工作的

关于FlyWay工作原理，官网给出了具体的工作原理图。官网原理图地址：https://flywaydb.org/getstarted/how

这里简单记录一下，仅做备忘。

1.1 场景一：使用Flyway从无到有创建数据库

技术分享图片

Flyway用‘schema_version_history‘数据表存放数据库schema的历史记录，跟踪数据库结构的变更；

由于刚开始数据库为空，Flyway找不到schema_version_history数据表，所以Flyway找不到它，就在数据库中创建了此表，

之后我们则需要在项目中定义Migration，通常用SQL或Java定义。

如下图所示，Flyway在运行时会顺序执行上图中的Migration1和Migration 2来实现对数据库的更新；同时‘schema_version_history‘表也会记录下这两次修改。

技术分享图片

‘schema_version_history‘表记录修改历史。如下图所示：

技术分享图片

说明：

脚本文件名(对应flyway_schema_history表的script字段)定义规则：
    常用格式如下：
    $PREFIX$VERSION__$REMARK.$SUBFIX
说明：
$prefix  表示 前缀，可在配置中指定，默认为 V；
$version 表示 版本号，版本号中也可以使用 . 或 _分隔，在解析时会将 _ 转换为 . 再保存到flyway_schema_history表的version字段中;
$remark  表示 备注，解析后会将这部分写入到描述字段中;
$subfix  表示 后缀，可在配置中指定，默认为 .sql ;
版本号与备注之前使用__分隔;
例如： V20200307_01__initial.sql

1.2 场景二：基于已有数据库更新

在此场景下，Flyway仍然会遍历项目中定义的各个Migration，并参照schema_version_history数据表，忽略版本号低于或等于当前版本的Migration，

剩下的就是Pending Migration(待处理迁移版本)，然后按照版本号顺序执行Pending Migration，如下图所示：

技术分享图片

‘schema_version_history‘表记录修改历史。如下图所示：

技术分享图片

因此，每当我们要对数据库的DDL或者DML进行迁移时，就只需要定义一个更高版本的Migration。

2、Spring Boot整合 Flyway

这部分也可以参考官网使用指导，官网整合地址：https://flywaydb.org/documentation/plugins/springboot

2.1 整合步骤

2.1.1 在项目的pom文件中导入Flyway依赖，目前官网最新版本如下：

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

2.1.2 在application.properties或者application.yml文件添加配置

# 说明，在spring boot 1.x中，属性前缀为flyway，在spring boot 2.x中为spring.flyway，这里需要区分不同版本
Spring.flyway:
  # 到新的环境中数据库中有数据，且没有flyway_schema_history表时，是否执行迁移操作。
    如果设置为false，在启动时会报错，并停止迁移;
    如果设置为true,则生成history表并完成所有的迁移，要根据实际情况设置;
  baseline-on-migrate: false
  # 执行时标记的tag 默认为<<Flyway Baseline>>
  baseline-description: <<Flyway Baseline>>
  # 是否启用flyway
  enabled: true
  # 检测迁移脚本的路径是否存在，如不存在，则抛出异常
  check-location: true
  # 脚本位置
  locations: classpath:db/migration
  # 在迁移时，是否校验脚本，假设V1.0__初始.sql已经迁移过了，在下次启动时会校验该脚本是否有变更过，则抛出异常
  validate-on-migrate: true
特别说明：
   如果非空数据库迁移，在目标数据库中手动建flyway_schema_history表并手动写入初始化的脚本记录,
   使flyway跳过最初的校验即可，后续可以保证版本的统一;

2.1.3 创建迁移数据库脚本文件

可以在项目模块下的 resources 目录下，手动创建 db/migration 目录，然后在该目录下创建数据库脚本，数据库脚本的命名方式可以参考上面的说明：

“脚本文件名(对应flyway_schema_history表的script字段)定义规则”，当然也可以看下面：

脚本文件名(对应flyway_schema_history表的script字段)定义规则：
    常用格式如下：
    $PREFIX$VERSION__$REMARK.$SUBFIX
说明：
$prefix  表示 前缀，可在配置中指定，默认为 V；
$version 表示 版本号，版本号中也可以使用 . 或 _分隔，在解析时会将 _ 转换为 . 再保存到flyway_schema_history表的version字段中;
$remark  表示 备注，解析后会将这部分写入到描述字段中;
$subfix  表示 后缀，可在配置中指定，默认为 .sql ;
版本号与备注之前使用__分隔;
例如： V20200307_01__initial.sql