SpringBoot整合Flyway实现数据库的初始化和版本管理

文章目录

  • 一、Flyway
    • 1、介绍
    • 2、业务痛点
    • 3、个人理解
  • 二、SpringBoot整合flyway
    • 1、整合
    • 2、SQL文件命名
    • 3、版本号校验算法
    • 4、工作流程
    • 5、注意事项

SpringBoot整合Flyway实现数据库的初始化和版本管理_第1张图片

一、Flyway

1、介绍

Flyway 是一款开源的数据库版本管理工具。它可以很方便的在命令行中使用,或者在Java应用程序中引入,用于管理我们的数据库版本。

官方文档:https://flywaydb.org/documentation/

2、业务痛点

日常开发中常有以下场景:

  • 一个系统有多套环境,更新表的SQL可能会遗漏某一个环境
  • 每次部署一个新环境,就得把所有库表的创建SQL手动执行一遍。多希望服务启动,就创建自己需要的库表
  • 每次发版要记录数据库变更信息,或者单独给出数据库升级脚本
  • 别人需求新增了SQL你不知道,系统一跑出来个数据库报错又得问人或者排错

3、个人理解

flyway,就像数据库界的Git。git做一个项目里代码的版本管理,flyway做一个项目数据库的版本管理。

  • Version control for your database.

  • Robust schema evolution across all your environments.

  • With ease, pleasure and plain SQL.

使用了 Flyway 之后,如果再想进行数据库版本升级,就不用改之前的数据库脚本了,直接创建新的数据库脚本,项目在启动时检测了有新的更高版本的脚本,就会自动执行

二、SpringBoot整合flyway

1、整合

  • 在pom文件中导入flyway依赖
<dependency>
  <groupId>org.flywaydbgroupId>
  <artifactId>flyway-coreartifactId>
  <version>5.2.4version>
dependency>
- 注意和springboot之间的版本适配问题
- flyway版本不建议太高
  • 配置文件application或者bootstrap中新加flyway的配置
# flyway 配置
spring:
  flyway:
    # 启用或禁用 flyway
    enabled: true
    # flyway 的 clean 命令会删除指定 schema 下的所有 table, 生产务必禁掉。这个默认值是 false 理论上作为默认配置是不科学的。
    clean-disabled: true
    # SQL 脚本的目录,多个路径使用逗号分隔 默认值 classpath:db/migration
    locations: classpath:db/migration
    #  metadata 版本控制信息表 默认 flyway_schema_history
    table: flyway_schema_history
    # 如果没有 flyway_schema_history 这个 metadata 表, 在执行 flyway migrate 命令之前, 必须先执行 flyway baseline 命令
    # 设置为 true 后 flyway 将在需要 baseline 的时候, 自动执行一次 baseline。
    baseline-on-migrate: true
    # 指定 baseline 的版本号,默认值为 1, 低于该版本号的 SQL 文件, migrate 时会被忽略
    baseline-version: 1
    # 字符编码 默认 UTF-8
    encoding: UTF-8
    # 是否允许不按顺序迁移 开发建议 true  生产建议 false
    out-of-order: false
    # 需要 flyway 管控的 schema list,这里我们配置为flyway  缺省的话, 使用spring.datasource.url 配置的那个 schema,
    # 可以指定多个schema, 但仅会在第一个schema下建立 metadata 表, 也仅在第一个schema应用migration sql 脚本.
    # 但flyway Clean 命令会依次在这些schema下都执行一遍. 所以 确保生产 spring.flyway.clean-disabled 为 true
    schemas: flyway
    # 执行迁移时是否自动调用验证   当你的 版本不符合逻辑 比如 你先执行了 DML 而没有 对应的DDL 会抛出异常
    validate-on-migrate: true
注意clean-disabled!!!

- 表示是否要清除已有库下的表
- 即执行脚本V1__xxx.sql,会先清除已有库下的表!!然后再执行脚本
- 设置为true,即确定关掉clean功能
  • resource/db/migration下添加数据库脚本(这个路径是上面配置中写的)

SpringBoot整合Flyway实现数据库的初始化和版本管理_第2张图片

  • 启动服务,显示控制台可以看到SQL被执行,并产生了历史记录表

SpringBoot整合Flyway实现数据库的初始化和版本管理_第3张图片

2、SQL文件命名

注意SQL的命名规范有要求:
SpringBoot整合Flyway实现数据库的初始化和版本管理_第4张图片

举例:V2.0.1.7__create_core_table.sql
  • V是前缀 表示这个文件只会被执行一次

  • 2.0.1.7为版本号 ,高版本的执行后不会再执行低版本的SQL。如2.0.1.7先执行了,2.0.1.6就不会被执行了

  • __ : 两个下划线表示分隔符

  • create_user_table :脚本功能表述

  • .sql: 后缀

注意flyway比较版本的先后是采用左对齐原则, 缺位用 0 代替,比如

- 1.0.1.1 比 1.0.1 高
- 1.0.10.0 比 1.0.9.9 高
- 1.0.10 和 1.0.010 一样高

需要执行多次的,以大写"R"开头,命名如R__insertInfo.sql ,R的脚本只要改变了就会执行,R不带版本号

3、版本号校验算法

flyway在升级数据库时会先计算之前已经升级过的脚本的checksum值和数据库的checkSum值进行比对,如果老脚本发生了变化后checkSum校验就会失败,从而抛出异常,checkSum计算算法为CRC32 (循环冗余校验码)算法

新增的脚本则会和数据库中的版本号进行比较,如果小于数据库存储的最后一个版本号,也不会继续执行。

4、工作流程

  • 项目启动,成功连接到数据库,flyway开始运行。
  • 第一次使用,flyway会创建flyway_schema_history表,用于记录SQL的执行记录
  • flyway扫描classpath:db/migration路径下的所有SQL脚本,并与flyway_schema_history表的记录对比
- 若表里没记录,即新SQL,执行并将信息写入history表
- R开头的文件只要发生修改,都会执行一遍
- V开头的文件,如果上次执行过后又发生了修改,则服务启动报错
- 想让V开头的已经执行过的文件再执行一次,就得清楚history表中的数据后再启动服务

  • 根据表中的sql记录最大版本号,忽略版本号不高于它的SQL脚本

5、注意事项

  • 报错后需要删除flyway_schema_history中记录,否则启动失败
  • V文件的优先级高于R,假如三个V迁移脚本和一个R(无论新建还是修改)一起执行,其中一个V报错,则V会全部执行完成且记录到flyway_schema_history中,而R不执行且不记录,删除表中报错记录后,重新启动,则执行原错误V和未执行的R
  • 多个要执行的R中,如果出现了其中一个出现了错误,则在其后的R都不执行
  • R的执行顺序根据命名来进行排序
  • 一个文件中ddl并不由一个事务管理,比如创建三个表,中间创建表语句报错,则第一个表还是会创建成功并且提交事务
  • 同一个迁移文件下假设都是DML(即insert、delete、update),那么如果中间出现错误,所有的DML语句都会回滚
  • 已经执行过的迁移文件(V)不能修改,否则启动报错
  • 版本号相同会报错(Found more than one migration with version 1.0.0.9)
  • 删除sql文件后启动会报错,报错如下:
If you removed this migration intentionally, run repair to mark the migration as
deleted.

你可能感兴趣的:(数据库,spring,boot,java)