一、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表中的数据后再启动服务
- 根据表中的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.