作者：烧鸡太子爷

起源：恒生LIGHT云社区

Flyway是什么

随着我的项目CICD接入,一键启动,麻利开发曾经成为降本提效的不二法宝,其中波及SQL的变更还不够智能和自动化,因而亟需一款工具可能帮忙开发及运维人员高效简便地实现SQL变更,Flyway正是能够满足咱们需要的一款工具。

当咱们关上Flyway的官网，在首页能够看到对于Flyway的一段英文介绍：

Flyway是数据库的版本控制，跨所有环境的持重架构演变。轻松、欢快和简略的SQL。

总的来说，Flyway是一款专为CI/CD打造的，能对数据库变更做版本控制的工具。

Flyway反对的数据库很多，支流的数据库都可能完满反对，官网摘抄如下：

Supported databases are Oracle, SQL Server (including Amazon RDS and Azure SQL Database), Azure Synapse

(Formerly Data Warehouse), DB2, MySQL (including Amazon RDS, Azure Database & Google Cloud SQL), Aurora MySQL,

MariaDB, Percona XtraDB Cluster, TestContainers, PostgreSQL (including Amazon RDS, Azure Database, Google Cloud

SQL, TimescaleDB, YugabyteDB & Heroku), Aurora PostgreSQL, Redshift, CockroachDB, SAP HANA, Sybase ASE,

Informix, H2, HSQLDB, Derby, Snowflake, SQLite and Firebird.

Flyway解决的问题

在我的项目或产品研发过程中，很难一开始就把业务理分明，把代码逻辑和数据库表设计好，因而代码和数据表也会在迭代周期内一直迭代。咱们都习惯应用SVN或者Git来对代码进行版本治理，次要是为了解决多人开发代码抵触和版本回退的问题。

其实，数据库的变更也须要版本控制，在日常开发和环境部署中，咱们常常会遇到上面的问题：

  • 在开发环境部署程序发现报错，定位是本人写的SQL脚本忘了在以后环境执行导致；
  • 从Git上新down下来的代码运行报错，定位发现是其余共事批改了的SQL脚本没有在以后环境执行导致；
  • 每次公布包都须要公布SQL文件包和应用程序的版本包；
  • 线上环境部署报错，发现是运维没有依照你投产文档外面阐明的SQL脚本执行程序操作执行导致；
  • 流水线能够自动化部署程序，然而SQL脚本还是须要手动执行或者流水线执行SQL脚本配置比拟繁琐；
  • 其余场景....

有了Flyway,这些问题都能够轻松的解决。Flyway能够对数据库进行版本治理，能够主动执行SQL，能疾速无效地用于迭代数据库表构造，并保障部署到测试环境或生产环境时，数据表都是保持一致的;

Flyway次要工作流程

Flyway工作流程如下：

1、我的项目启动，应用程序实现数据库连接池的建设后，Flyway主动运行。

2、首次应用时，Flyway会创立一个flyway_schema_history表，用于记录sql执行记录。

3、Flyway会扫描我的项目指定门路下(默认是classpath:db/migration)的所有sql脚本，与flyway_schema_history表脚本记录进行比对。如果数据库记录执行过的脚本记录，与我的项目中的sql脚本不统一，Flyway会报错并进行我的项目执行。

4、如果校验通过，则依据表中的sql记录最大版本号，疏忽所有版本号不大于该版本的脚本。再依照版本号从小到大，一一执行其余脚本。

在SpringBoot我的项目应用Flyway

Flyway既反对应用客户端command-lineclient命令行形式也反对JAVA API形式降级数据库，本文只介绍JAVA API以Maven引入插件形式的应用，更多形式能够查看官网；

引入依赖

在start.spring.io上新建一个SpringBoot工程，引入数据库驱动依赖等，同时引入Flyway的依赖，这个步骤比较简单，不做过多阐明（本文示例应用的是Mysql数据库）；

<dependency>    <groupId>org.flywaydb</groupId>    <artifactId>flyway-core</artifactId>    <version>7.14.0</version><!-- 截至发稿前，官网最新版本是7.14.0 --></dependency>

增加Flyway配置

spring:  # 数据库连贯配置  datasource:    driver-class-name: com.mysql.cj.jdbc.Driver    url: jdbc:mysql://localhost:3306/xukj_flyway?useUnicode=true&characterEncoding=utf8&serverTimezone=GMT    username: flyway    password: xxx  flyway:    # 是否启用flyway    enabled: true       # 编码格局，默认UTF-8    encoding: UTF-8    # 迁徙sql脚本文件寄存门路，默认db/migration    locations: classpath:db/migration    # 迁徙sql脚本文件名称的前缀，默认V    sql-migration-prefix: V    # 迁徙sql脚本文件名称的分隔符，默认2个下划线__    sql-migration-separator: __    # 迁徙sql脚本文件名称的后缀    sql-migration-suffixes: .sql    # 迁徙时是否进行校验，默认true    validate-on-migrate: true    # 当迁徙发现数据库非空且存在没有元数据的表时，主动执行基准迁徙，新建schema_version表    baseline-on-migrate: true

创立SQL脚本

我的项目创立当前，在src/resources下有 db/migration（或db.migration）目录，在其中创立对应的SQL文件，基于约定因为配置的准则，不同的类型通过文件命名形式进行辨别

Flyway对数据库的所有更改都称为迁徙；版本迁徙(Versioned Migrations)以V结尾，只会执行一次；回退迁徙(Undo Migrations)以U结尾，执行一旦产生破坏性更改，就会很麻烦，我的项目中个别不必；可反复执行迁徙(Repeatable Migrations)以R结尾，每次批改后都会从新执行。

总结如下：

  1. 仅须要被执行一次的SQL命名以大写的"V"结尾，前面跟上"0~9"数字的组合,数字之间能够用“.”或者下划线"_"宰割开，而后再以两个下划线宰割，其后跟文件名称，最初以.sql结尾。比方，V2020.00.000_1__create_table.sql，V202001.00.000_2__insertTable.sql，V2.1.5__create_table.sql。
  2. 可反复运行的SQL，则以大写的“R”结尾，前面再以两个下划线宰割，其后跟文件名称，最初以.sql结尾。比方，R__addTable.sql，R__update_user.sql。
  3. 版本号须要惟一，否则Flyway执行会报错；如果V__脚本.sql，曾经执行过了，不能批改外面的内容，再次执行Flyway就会报错。R——脚本.sql,如有变动能够执行屡次。
  4. V结尾的SQL执行优先级要比R结尾的SQL优先级高。

如下，咱们筹备了三个脚本，别离为：

1、V2020.00.000_1__create_table.sql，代码如下，目标是创立一张表，且只执行一次

CREATE TABLE `test_flyway_table` (  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',  `time` datetime NOT NULL COMMENT '创立工夫',  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

2、V202001.00.000_2__insertTable.sql，代码如下，目标是往表中插入一条数据，且只执行一次

INSERT INTO `test_flyway_table` VALUES ('1', '2021-06-28 17:48:48');

3、R__addTable.sql，代码如下，目标是每次启动如果有变动，则执行一次

update `test_flyway_table` set time = '2021-08-23 17:48:48' where id =1;

对应目录截图如下：

运行

依照下面配置实现，曾经足够咱们开始运行了，此时，咱们第一次启动我的项目，如果配置没有谬误，运行截图如下：

此时，咱们刷新数据库，能够看到Flyway的历史记录表曾经生成并插入了三个版本的记录：

而且，表也曾经创立好了并有一条数据：

此时不做任何扭转，重启程序，日志如下：

日志显示表没有变动，不做变更，查看两张表的内容也无变动。

如果咱们批改V202001.00.000_2__insertTable.sql脚本，重启程序，就会报错，提示信息如下：

Caused by: org.flywaydb.core.api.exception.FlywayValidateException: Validate failed: Migrations have failed validationMigration checksum mismatch for migration version 202001.00.000.2-> Applied to database : 1190158040-> Resolved locally: 843339817. Either revert the changes to the migration, or run repair to update the schema history.

如果咱们批改R__addTable.sql脚本，重启程序，脚本会再次执行，并且Flyway的历史记录表也会减少本次执行的记录。

Flyway的执行效率

为了验证Flyway我的项目数据库迭代了较久工夫，积攒了几百个Sql当前是否会拖慢我的项目的启动速度？进行了一个对照组试验：

场景（sql文件管制在10K以内）执行均匀时长（单位:秒）
放1个曾经被执行过的SQL脚本,重复启动我的项目11.1
放25个曾经被执行过的SQL脚本,重复启动我的项目11.4
放50个曾经被执行过的SQL脚本,重复启动我的项目11.6
放100个曾经被执行过的SQL脚本,重复启动我的项目12.19

脚本在历史记录表中有记录，即便有几百条SQL脚本，每次我的项目启动只执行单次迭代的脚本，所以耗时次要来源于两个方面：

  • Flyway顺次读取脚本中内容时的IO开销;
  • Flyway计算脚本checksum值的算法开销;

对于IO开销而言，每个脚本如果不是波及大量的数据变更,只是表构造的变更,脚本的大小都十分小,能够不思考.事实上Flyway也不适宜大量的数据变更时应用,因而IO开销对启动耗时的增量根本能够疏忽

Flyway计算checksum值采纳的是驰名的CRC32(循环冗余校验码)算法，该算法是数据通信畛域中最罕用的一种查错校验码，其特色是信息字段和校验字段的长度能够任意选定。循环冗余查看（CRC）是一种数据传输检错性能，对数据进行多项式计算，并将失去的后果附在帧的前面，接管设施也执行相似的算法，以保障数据传输的正确性和完整性。为了验证算法计算效率，做了如下试验：

场景执行均匀时长（单位:毫秒）
读取一个超大文件,约1M,并进行计算，重复执行屡次48
读取一个失常大小的SQL脚本,约10K,并进行计算，重复执行屡次4

由此可见,即使是有上百个失常大小的sql,计算checksum值也不会消耗太多的工夫,根本都能够在1秒内实现,所以接入Flyway后也不用放心会有历史包袱。