What?
Flyway一款开源的数据库版本管理工具,它更倾向于规约优于配置的方式。Flyway可以独立于应用实现管理并跟踪数据库变更,支持数据库版本自动升级,并且有一套默认的规约,不需要复杂的配置,Migrations可以写成SQL脚本,也可以写在Java代码中,不仅支持Command Line和Java API,还支持Build构建工具和Spring Boot等,同时在分布式环境下能够安全可靠地升级数据库,同时也支持失败恢复等。
通俗易懂的讲,像git管理代码一样管理数据库的sql,从而做到SQL同步。
Why?
现状以及存在问题
在公司都是团队伙伴协同开发,sql的变动很难做到全部有迹可循,而且当存在多套环境,而且系统运行环境每晚与线上同步,经常性造成因为SQL变动造成开发,测试,仿真等环境使用异常,公司目前采取的解决方案是将让大家变动的SQL放到一个脚本中,每次数据同步后自动执行脚本内容,但是脚本目前只应用于开发,测试。仿真环境需要手动操作,而且如果忘记配置到脚本中,在其他环境同样会出现异常。系统和sql变动并非原子性的操作,非常容易发生问题,还有一点,就是当没有配置脚本的开发未在公司时,大部分恢复环境都需要远程沟通或者等待,这也是很浪费一种现象存在。即便这样,例如表结构的变动仍然无迹可寻。
解决
1、sql变动可以被追踪
2、避免多环境脚本忘记配置造成的不可用
3、减轻运维工作量,现在每个sql变动都需要审核平台工单批准,即便是正常上线的项目,这样省去开发->负责人->dba的审核流程
How?
因为springboot版本的原因,暂时无法使用flyway的最新版本,小编使用的版本为5.2.4
1、引入maven依赖
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.2.4</version>
</dependency>
2、引入maven插件
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
</plugin>
3、application.yml相关配置
flyway:
enabled: true //是否启用,默认启用
//使用生成基准默认为false(半路接入的项目,需要配置,相当于画一个分割线,在基准线之前的sql不予管理,
默认从此之后的sql变动flyway处理),如果全新的项目schema为空可以使用默认值false,
如果迁移项目不配置此项会造成flyway相关类初始化不成功,项目无法启动
baselineOnMigrate: true
//配置sql加载路径,默认为db/migration,配置此项可以解决配置sql,却不执行的问题
locations: db/migration,db/migration-mock
//sql版本是否可以不按顺序执行,默认为false,例如,项目配置了V1,V3sql都执行过,但是此时加入V2,如果采用默认值V2不会执行,设置为true,
此时V2的sql将被执行,建议开发环境开启,生产环境禁用
outOfOrder: true
4、创建sql存放目录
在resource下创建db/migration
配置上述几项内容,此时springboot和flyway集成过程完成。
关于flyway的几项内容,
1、关于sql文件命名
其中的文件名由以下部分组成,除了使用默认配置外,某些部分还可自定义规则。
- prefix: 可配置,前缀标识,默认值
V
表示Versioned,R
表示Repeatable - version: 标识版本号,由一个或多个数字构成,数字之间的分隔符可用点
.
或下划线_
- separator: 可配置,用于分隔版本标识与描述信息,默认为两个下划线
__
- description: 描述信息,文字之间可以用下划线或空格分隔
- suffix: 可配置,后续标识,默认为
.sql
注意:
V代表版本,需要有数字用于版本号的标识
R代表此SQL文件可以重复执行,只有R后面不能加数字,当带有R作为开头命名的sql文件,每当sql文件有变动,整个SQL文件都会被执行,所以使用此种需要慎重
2、全部配置项
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.
总结
整个开发过程中配套的工具都已经很完善了,只是当前的知识储备还很有限,不能飘,需要沉下来,认真解决问题,积累,厚积薄发,不负时光,💪!