Flyway的使用
环境：SpringBoot 2.0.4.RELEASE
为什么要用Flyway？
开发人员在合作的时候经常遇到以下场景：
1.开发人员A在自己的本地数据库做了一些表结构的改动，并根据这些改动调整了DAO层的代码，然后将代码上传到svn或git等版本控制服务器上。此时如果开发人员B拉取了A的代码改动，在运行项目的时候很可能会报错，因为B的本地SQL数据库并没有修改。
2.在项目上线的时候，当服务器拉取的版本控制服务器的最新修改后，必须同时运行SQL数据库的修改脚本，如果忘了跑数据库脚本，那么会出现严重的问题。
传统的解决方案就是在一个固定的文件夹中，将需要跑的SQL脚本放在里面。开发人员在合作的时候，A修改了数据库，在B遇到问题的时候，可能需要交流沟通一下，去跑需要的脚本。在项目上线的过程中，也是运维人员在规定的文件夹中，找到需要跑的SQL脚本。运行它们。
Flyway等migration工具就是要把开发人员和运维人员从以上这些场景的繁琐工作中解放出来，如果使用maven的话，那么在项目编译（SpringBoot运行Application）的时候，SQL数据库的改动就自动进入数据库，只要启动成功，开发或者运维人员对SQL数据库的migrate过程是无感知的，项目依然可以照常运行。
Flyway是什么？
官方网站：https://flywaydb.org/
Flyway是一个简单开源数据库版本控制器（约定大于配置），主要提供migrate、clean、info、validate、baseline、repair等命令。它支持SQL（PL/SQL、T-SQL）方式和Java方式，支持命令行客户端等，还提供一系列的插件支持（Maven、Gradle、SBT、ANT等）。
Flyway最核心的就是用于记录所有版本演化和状态的MetaData表，Flyway首次启动会创建默认名为SCHEMA_VERSION的元素局表。 表中保存了版本，描述，要执行的sql脚本等；
sql脚本的格式：V + 版本号 + 双下划线(__) + 描述 + 结束符(.sql)
例如：V1__INIT_DATABASE.sql
命令解释：
Migrate
Migrate 是指把数据 Schema 迁移到最新版本，在 Migrate 时会检查 MetaData 元数据表，如果不存在就创建 MetaData 表，MetaData 用于记录数据库历史变更等信息；
Migrate会扫描指定文件系统或者 classpath 下的 Migrations。会与 MetaData 中的记录进行对比，进行版本升级；
clean
清除掉对应数据库 Schema 中所有的对象，包括表结构，视图，存储过程等，clean 操作在 dev 和 test 阶段很好用；
info
用于打印所有的 Migrations 的详细和状态信息，也是通过 MetaData 和 Migrations 完成的，可以快速定位当前的数据库版本；
validate
验证以及apply的Migrations是否有变更，默认开启的；原理是对比MetaData表与本地Migrations的checkNum值，如果值相同则验证通过，否则失败
baseline
对已经存在数据库Schema结构的数据库一种解决方案。实现在非空数据库新建MetaData表，并把Migrations应用到该数据库；也可以应用到已有表结构的数据库中也可以实现添加Metadata表
repair
repair操作能够修复metaData表，该操作在metadata出现错误时很有用
用途：
1）：移除失败的Migration记录，只针对不支持DDL事务的数据库
SpringBoot中使用Flyway管理数据库版本
一、添加maven依赖及插件
|
1
2
3
4
5
6
7
8
9
10
11
|
<!-- https://mvnrepository.com/artifact/org.flywaydb/flyway-core -->
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.0.7</version>
</dependency>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
</plugin>
|
添加插件的目的是为了使用上面讲到的一些命令：如下图：
二、开启Flyway支持、配置Flyway
|
1
2
3
4
5
6
7
8
9
|
######################FlyWay#######################
# 在没有元数据表的情况下，针对非空Schema执行迁移时是否自动调用基线。 （默认值：false）
spring.flyway.baseline-on-migrate=true
# 下面几个配置不写也行，都是默认配置，这里写了是方便以后改
# 执行基线时用来标记已有Schema的版本。（默认值：1）
spring.flyway.baseline-version=1
spring.flyway.enabled=true
spring.flyway.sql-migration-prefix=V
spring.flyway.locations=classpath:db/migration
|
三、在resource目录下创建db/migration目录添加sql脚本
如图：
下面是 V1.0.0.20190509.0957__flyway_test.sql 脚本
|
1
2
3
4
5
6
7
8
9
|
use `spring_boot_building`;
DROP TABLE IF EXISTS `table1`;
CREATE TABLE `table1` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(20) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
|
spring_boot_building 是我的项目连接的数据库
四、验证是否成功
启动项目，看启动日志：
打开数据库管理工具，查看数据库：
五、SQL文件版本号命名的规范
每个公司的规范肯定不一样.开发时,只需要项目内遵循该规范即可,规范的确定并没有对错.提供一种sql文件命名规范仅供大家参考。
遇到的问题
因为我的项目数据库连接池使用的是Druid，在启动项目时发现报异常sql injection violation, part alway true condition not allow，原因是Flyway通过 SQL 脚本来执行数据库的建立与更新。当同时集成了 Druid 和 Flyway 之后，Druid 的 wall 防火墙极可能直接干预 SQL 脚本的操作，继而导致 Flyway 执行中断。
网上教程是去掉wall防火墙配置，我试了确实可以，但是个人觉得这种做法不安全，应该还有其他的方法。
到此这篇关于Java 中Flyway的使用详解的文章就介绍到这了,更多相关java Flyway 使用内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/qq_34845394/article/details/90025456