SpringBoot整合Flyway实现数据库的初始化和版本管理操作
作者：-代号9527
一、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.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>5.2.4</version> </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下添加数据库脚本（这个路径是上面配置中写的）
启动服务，显示控制台可以看到SQL被执行，并产生了历史记录表
2、SQL文件命名
注意SQL的命名规范有要求：
举例：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表中的数据后再启动服务
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.
到此这篇关于SpringBoot整合Flyway实现数据库的初始化和版本管理的文章就介绍到这了,更多相关SpringBoot整合Flyway内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！