Flyway数据库版本控制器理解与使用

1、Flyway简介

Flyway是一款开源的数据库版本管理工具，它更倾向于规约优于配置的方式。Flyway可以独立于应用实现管理并跟踪数据库变更，支持数据库版本自动升级，并且有一套默认的规约，不需要复杂的配置，Migrations可以写成SQL脚本，也可以写在Java代码中，不仅支持Command Line和Java API，还支持Build构建工具和Spring Boot等，同时在分布式环境下能够安全可靠地升级数据库，同时也支持失败恢复等。

2、为什么使用FlyWay

通常在项目开始时会针对数据库进行全局设计，但在开发产品新特性过程中，难免会遇到需要更新数据库Schema的情况，比如：添加新表，添加新字段和约束等，这种情况在实际项目中也经常发生。那么，当开发人员完成了对数据库更的SQL脚本后，如何快速地在其他开发者机器上同步？并且如何在测试服务器上快速同步？以及如何保证集成测试能够顺利执行并通过呢？
假设以Spring Boot技术栈项目为例，可能有人会说，本地使用Hibernate自动更新数据库Schema模式，然后让QA或DEV到测试服务器上手动执行SQL脚本，同时可以写一个Gradle任务自动执行更新。
其实，以上问题可以通过Flyway工具来解决，Flyway可以实现自动化的数据库版本管理，并且能够记录数据库版本更新记录，Flyway官网对Why database migrations结合示例进行了详细的阐述，有兴趣可以参阅一下。

3、支持的数据库

目前Flyway支持的数据库还是挺多的，包括：Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL(including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL(including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql, Derby, SQLite, SAP HANA, solidDB, Sybase ASE and Phoenix。

4、Flyway常用命令

4.1 Migrate

Migrate是指把数据库Schema迁移到最新版本，是Flyway工作流的核心功能，Flyway在Migrate时会检查Metadata(元数据)表，如果不存在会创建Metadata表，Metadata表主要用于记录版本变更历史以及Checksum之类的。

4.2 Clean

Clean相对比较容易理解，即清除掉对应数据库Schema中的所有对象，包括表结构，视图，存储过程，函数以及所有的数据等都会被清除（慎用）

4.3 Info

Info用于打印所有Migrations的详细和状态信息，其实也是通过Metadata表和Migrations完成的，Info能够帮助快速定位当前的数据库版本，以及查看执行成功和失败的Migrations。下图很好地示意了Info打印出来的信息。

4.4 Validate

Validate是指验证已经Apply的Migrations是否有变更，Flyway是默认是开启验证的。
Validate原理是对比Metadata表与本地Migrations的Checksum值，如果值相同则验证通过，否则验证失败，从而可以防止对已经Apply到数据库的本地Migrations的无意修改。

4.5 Baseline

Baseline针对已经存在Schema结构的数据库的一种解决方案，即实现在非空数据库中新建Metadata表，并把Migrations应用到该数据库。
Baseline可以应用到特定的版本，这样在已有表结构的数据库中也可以实现添加Metadata表，从而利用Flyway进行新Migrations的管理了。

4.6 Repair

Repair操作能够修复Metadata表，该操作在Metadata表出现错误时是非常有用的。

Repair会修复Metadata表的错误，通常有两种用途：
移除失败的Migration记录，该问题只是针对不支持DDL事务的数据库。
重新调整已经应用的Migratons的Checksums值，比如：某个Migratinon已经被应用，但本地进行了修改，又期望重新应用并调整Checksum值，不过尽量不要这样操作，否则可能造成其它环境失败。

5、与SpringBoot集成

pom.xml依赖

<dependency>
    <groupId>org.flywaydbgroupId>
    <artifactId>flyway-coreartifactId>
    <version>5.0.7version>
dependency>
<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-jdbcartifactId>
dependency>
<dependency>
    <groupId>mysqlgroupId>
    <artifactId>mysql-connector-javaartifactId>
dependency>

application.properties配置文件信息

#SpringBoot2.0以后使用spring开头（如果已经配置数据源可以不用配置sprin#g.flyway.url,spring.flyway.user,spring.flyway.password）
spring.flyway.url=jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8
spring.flyway.user=root
spring.flyway.password=root
spring.flyway.enabled=true
spring.flyway.check-location=true
spring.flyway.locations=classpath:db/migration
spring.flyway.validate-on-migrate=true
spring.flyway.clean-on-validation-error=true
spring.flyway.baseline-on-migrate=true

其他属性含义如下图所示：

在db/migration目录下创建需要更新的SQL，命名规则为


配置完毕启动项目，启动日志中会出现类似如下信息，数据库会增加版本记录表，

6、注意事项

6.1 数据脚本的命名规则：

V+版本号++脚本名称+后缀
例如：V1.1__create_table.sql
其中flyway.sql-migration-prefix配置前缀，默认V
flyway.sql-migration-separator配置分隔符，默认
flyway.sql-migration-suffix配置脚本后缀，默认.sql
特别注意：V1__***.sql == V1.0__***.sql
V1.1__***.sql == V1.1.0__***.sql
所以配置时，最好设置显示递增的版本号，否则会报错

6.2 基线版本号和脚本文件版本号的关系

文件的版本号必须 > 基线初始版本号，否则不会执行你的脚本
比如基线默认版本号为1，所以你的脚本版本号必须大于1，例如V1.1****

6.3 脚本文件的特殊性：

A 如果项目已经执行了过了某个脚本，那么这个脚本不能删除，也不能修改，否则在项目启动时会报错，删除了则是找不到以前执行的文件，修改了则是在对比checksum时报不一致。所以如果在sql脚本有问题，第一次跑没有成功，重新跑时，要么重新定义脚本的版本号，要么删除表schema_version的当前版本记录
B 两个脚本的版本号应该严格不同，不能出现1中的特别注意项

6.4 地雷配置项：

flyway.clean-on-validation-error：这个配置项一定要小心了，如果配置为true，当你的sql脚本执行失败时，就会执行删除库中所有表的操作，即之前的clean操作，所以一定要慎重，慎重，慎重！！！

6.5 Druid 与 Flyway 的冲突

Flyway通过 SQL 脚本来执行数据库的建立与更新。当同时集成了 Druid 和 Flyway 之后，Druid 的 wall 防火墙极可能直接干预 SQL 脚本的操作，继而导致 Flyway 执行中断。在项目开发的过程中，配置了以下防火墙属性以放行 Flyway 的 SQL 操作。

spring:
  datasource:
    druid:
      wall:
        config:
          variantCheck: false
          noneBaseStatementAllow: true
          commentAllow: true
          multiStatementAllow: true

到此Flyway已经集成完毕，希望能够帮助到大家！