Springboot2（48）集成flyway进行数据库版本管理

源码地址

springboot2教程系列

pom.xml添加maven依赖

<!-- https://mvnrepository.com/artifact/org.flywaydb/flyway-core -->
<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>5.2.4</version>
</dependency>

application.yml文件添加Flyway配置

2.x的版本

spring.flyway.locations: classpath:/db/migration
spring.flyway.out-of-order: true

1.x版本

flyway.locations: classpath:db/migration

spring boot flyway 配置说明

flyway.baseline-description对执行迁移时基准版本的描述.
flyway.baseline-on-migrate当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.
flyway.baseline-version开始执行基准迁移时对现有的schema的版本打标签，默认值为1.
flyway.check-location检查迁移脚本的位置是否存在，默认false.
flyway.clean-on-validation-error当发现校验错误时是否自动调用clean，默认false.
flyway.enabled是否开启flywary，默认true.
flyway.encoding设置迁移时的编码，默认UTF-8.
flyway.ignore-failed-future-migration当读取元数据表时是否忽略错误的迁移，默认false.
flyway.init-sqls当初始化好连接时要执行的SQL.
flyway.locations迁移脚本的位置，默认db/migration.
flyway.out-of-order是否允许无序的迁移，默认false.
flyway.password目标数据库的密码.
flyway.placeholder-prefix设置每个placeholder的前缀，默认${.
flyway.placeholder-replacementplaceholders是否要被替换，默认true.
flyway.placeholder-suffix设置每个placeholder的后缀，默认}.
flyway.placeholders.[placeholder name]设置placeholder的value
flyway.schemas设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema.
flyway.sql-migration-prefix迁移文件的前缀，默认为V.
flyway.sql-migration-separator迁移脚本的文件名分隔符，默认__
flyway.sql-migration-suffix迁移脚本的后缀，默认为.sql
flyway.tableflyway使用的元数据表名，默认为schema_version
flyway.target迁移时使用的目标版本，默认为latest version
flyway.url迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源
flyway.user迁移数据库的用户名
flyway.validate-on-migrate迁移时是否校验，默认为true.

如何使用Flyway?

这里将主要关注在Gradle和Spring Boot中集成并使用Flyway，数据库通常会采用MySQL、PostgreSQL、H2或Hsql等。

正确创建Migrations

Migrations是指Flyway在更新数据库时是使用的版本脚本，比如：一个基于Sql的Migration命名为V1__init_tables.sql，内容即是创建所有表的sql语句，另外，Flyway也支持基于Java的Migration。Flyway加载Migrations的默认Locations为classpath:db/migration，也可以指定filesystem:/project/folder，其加载是在Runtime自动递归地执行的。

除了需要指定Location外，Flyway对Migrations的扫描还必须遵从一定的命名模式，Migration主要分为两类：Versioned和Repeatable。

• Versioned migrations
  一般常用的是Versioned类型，用于版本升级，每一个版本都有一个唯一的标识并且只能被应用一次，并且不能再修改已经加载过的Migrations，因为Metadata表会记录其Checksum值。其中的version标识版本号，由一个或多个数字构成，数字之间的分隔符可以采用点或下划线，在运行时下划线其实也是被替换成点了，每一部分的前导零会被自动忽略。
• Repeatable migrations
  Repeatable是指可重复加载的Migrations，其每一次的更新会影响Checksum值，然后都会被重新加载，并不用于版本升级。对于管理不稳定的数据库对象的更新时非常有用。Repeatable的Migrations总是在Versioned之后按顺序执行，但开发者必须自己维护脚本并且确保可以重复执行，通常会在sql语句中使用CREATE OR REPLACE来保证可重复执行。

默认情况下基于Sql的Migration文件的命令规则如下图所示：

其中的文件名由以下部分组成，除了使用默认配置外，某些部分还可自定义规则。

• prefix: 可配置，前缀标识，默认值V表示Versioned，R表示Repeatable
• version: 标识版本号，由一个或多个数字构成，数字之间的分隔符可用点.或下划线_
• separator: 可配置，用于分隔版本标识与描述信息，默认为两个下划线__
• description: 描述信息，文字之间可以用下划线或空格分隔
• suffix: 可配置，后续标识，默认为.sql

在resource目录下创建db/migration目录添加sql脚本

报sql injection violation, comment not allow异常

创建flyway_schema_history表报错,因为flyway_schema_history创建表语句有注释,导致durid防火墙拦截器.解决方法:去掉即可,或者手动创建flyway_schema_history表.

flyway 最佳实践

SQL 的文件名

开发环境和生产环境的 migration SQL 不共用. 开发过程往往是多人协作开发, DB migration 也相对比较频繁, 所以 SQL 脚本会很多. 而生产环境 DB migration 往往由 DBA 完成, 每次升级通常需要提交一个 SQL 脚本.

• (1). 开发环境 SQL 文件建议采用时间戳作为版本号.

  开发环境 SQL 文件建议采用时间戳作为版本号, 多人一起开发不会导致版本号争用, 同时再加上生产环境的版本号, 这样的话, 将来手工 merge 成生产环境 V1.2d migration 脚本也比较方便, SQL 文件示例:
  V1.2.20180317.10.59__Unique_User_Names.sql
  V1.2.20180317.14.59__Add_SomeTables.sql

• (2). 生产环境 SQL 文件, 应该是手动 merge 开发环境的 SQL 脚本, 版本号按照正常的版本, 比如

  V2.1.5_001__Unique_User_Names.sql

migration 后的SQL 脚本不应该再被修改.

spring.flyway.out-of-order 取值 true /false

对于开发环境, 可能是多人协作开发, 很可能先 apply 了自己本地的最新 SQL 代码, 然后发现其他同事早先时候提交的 SQL 代码还没有 apply, 所以 开发环境应该设置 spring.flyway.out-of-order=true, 这样 flyway 将能加载漏掉的老版本 SQL 文件; 而生产环境应该设置 spring.flyway.out-of-order=false

多个系统公用要 DB schema

很多时候多个系统公用一个 DB schema , 这时候使用 spring.flyway.table 为不同的系统设置不同的 metadata 表, 缺省为 flyway_schema_history