各个互联网公司都在用的开源数据库控制器Flyway

开源的数据库控制器

在开发中，咱们常常会遇到上线数据库表的状况，代码上咱们有git，svn这样优秀的版本控制软件，可是数据库的迭代咱们不能使用手工的方式迭代吧？或者说每次上线前手工去数据库执行。这样带来的便捷性就会有很大问题，执行者须要跟开发屡次核对数据库执行脚本语句确保正确性后才执行。

为了更好的管理好各个环境的数据库版本，咱们能够在项目中增长Flyway来管理数据表的版本。

Flyway是什么呢？

Flyway是一款开源的数据库版本管理工具，利用简单的配置，独立跟踪进行数据版本的迭代。

Version control for your database.Robust schema evolution across all your environments. With ease, pleasure and plain SQL.

简单的来讲，使用Flyway来帮助咱们执行数据库的脚本，打破原先的脚本执行的规范。

原先的流程规范

原先部署程序的流程是这样的。

1. 开发人员将代码应用程序，脚本汇总到代码仓库上，好比svn或者git上。
2. DBA或者运维人员根据脚本检查，备份，执行；先完成数据库的升级。
3. 而后再将程序包进行部署安装升级。

如今的数据执行流程

1. 开发人员将应用程序，代码上传至代码仓库上。
2. 部署人员直接打包程序、或者使用docker打包程序，替换完成升级。开始执行Flyway

这样的步骤中没有引入docker的概念，引入docker，部署流程还会存在变更，甚至自动化ci等等都是能够进行流程方面的优化，也带来更高的工做效率。

Flyway 如何工做

flyway在使用的时候会在一个空的数据库里面建立一张表，表名通常是flyway_schema_history，老版本的名字是schema_version.

表结构以下： 记录了表变动的历史
CREATE TABLE `flyway_schema_history` (
  `installed_rank` int(11) NOT NULL,
  `version` varchar(50) DEFAULT NULL,
  `description` varchar(200) NOT NULL,
  `type` varchar(20) NOT NULL,
  `script` varchar(1000) NOT NULL,
  `checksum` int(11) DEFAULT NULL,
  `installed_by` varchar(100) NOT NULL,
  `installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `execution_time` int(11) NOT NULL,
  `success` tinyint(1) NOT NULL,
  PRIMARY KEY (`installed_rank`),
  KEY `flyway_schema_history_s_idx` (`success`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

复制代码

执行流程：

• 在应用中建立数据库脚本，flyway中称之为migration.
• 程序启动，flyway根据表中 的记录决定是否执行应用中的migration。
• 执行结果会就算出来checksum，进行对比。版本同样里面内容出现变化，migration就会出现问题。因此在线上环境，必定不能修改原先已经完成的migration内容。
• 插入成功后，会在版本库中新增一条记录。

Java中的使用

项目背景

1. 该使用咱们是创建在Spring boot 1.5.10版本上。在Spring boot 2.0版本后存在不一样的使用。
2. 构建项目使用的gradle4.9+。

源码实现

• 在项目中引入flyway

compile("org.flywaydb:flyway-core:5.1.3")
复制代码

• 建立文件目录db.migration(默认是这样的文件目录结构，能够更改，看附录文件)

• 注意sql脚本的文件命名 其中的文件名由如下部分组成，除了使用默认配置外，某些部分还可自定义规则。

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

  

启动springboot项目

启动项目以后就会在数据库中执行脚本中的sql内容。

更多参数配置列表

在介绍的使用过程当中，有不少参数能够进行配置，定制属于本身个性化的flyway内容。注意不一样的Spring boot 项目有不一样的配置内容。

flyway.baseline-description= # 执行基线时标记已有Schema的描述
flyway.baseline-version=1 # 基线版本默认开始序号 默认为 1. 
flyway.baseline-on-migrate=false # 针对非空数据库是否默认调用基线版本 ， 这也是咱们上面版本号从 2 开始的缘由
flyway.check-location=false # 是否开启脚本检查 检查脚本是否存在 默认false
flyway.clean-on-validation-error=false # 验证错误时 是否自动清除数据库 高危操做！！！
flyway.enabled=true # 是否启用 flyway.
flyway.encoding=UTF-8 # 脚本编码.
flyway.ignore-failed-future-migration=true # 在读元数据表时，是否忽略失败的后续迁移.
flyway.init-sqls= # S获取链接后当即执行初始化的SQL语句
flyway.locations=classpath:db/migration # 脚本位置， 默认为classpath: db/migration.
flyway.out-of-order=false # 是否容许乱序（out of order）迁移
flyway.placeholder-prefix= # 设置每一个占位符的前缀。 默认值： ${ 。 
flyway.placeholder-replacement=true # 是否要替换占位符。 默认值： true 。 
flyway.placeholder-suffix=} # 设置占位符的后缀。 默认值： } 。 
flyway.placeholders.*= # 设置占位符的值。
flyway.schemas= # Flyway管理的Schema列表，区分大小写。默认链接对应的默认Schema。
flyway.sql-migration-prefix=V # 迁移脚本的文件名前缀。 默认值： V 。 
flyway.sql-migration-separator=__ # 迁移脚本的分割符 默认双下划线
flyway.sql-migration-suffix=.sql # 迁移脚本的后缀 默认 .sql
flyway.table=schema_version # Flyway使用的Schema元数据表名称 默认schema_version
flyway.url= # 待迁移的数据库的JDBC URL。若是没有设置，就使用配置的主数据源。
flyway.user= # 待迁移数据库的登陆用户。
flyway.password= # 待迁移数据库的登陆用户密码。
flyway.validate-on-migrate=true # 在运行迁移时是否要自动验证。 默认值： true 。
复制代码

总结

使用flyway帮助咱们解决了每次汇总数据库sql的问题，而且也不须要人工干预数据库的执行。大大提升效率与工做的流程。

参考资料以下：

blog.waterstrong.me/flyway-in-p… 快速掌握和使用Flyway blog.csdn.net/chenleiking… Flyway简介

·END·

路虽远，行则必至

本文原发于 同名微信公众号「胖琪的升级之路」，回复「1024」你懂得，给个赞呗。

微信ID：YoungRUIQ