flyway使用简介

官网

https://flywaydb.org/

背景

Flyway是独立于数据库的应用、管理并跟踪数据库变更的数据库版本管理工具。用通俗的话讲，Flyway可以像Git管理不同人的代码那样，管理不同人的sql脚本，从而做到数据库同步。Flyway是一个简单开源数据库版本控制器（约定大于配置），主要提供migrate、clean、info、validate、baseline、repair等命令。

它支持SQL（PL/SQL、T-SQL）方式和Java方式，支持命令行客户端等，还提供一系列的插件支持（Maven、Gradle、SBT、ANT等）。

流程

1、 首先配置好flyway的基本信息后，运行项目，会在数据库表中默认新建一个数据表用于存储flyway的运行信息，默认的数据库名：flyway_schema_history

2、 紧接着Flyway将开始扫描文件系统或应用程序的类路径进行迁移。然后，Flyway的数据迁移将基于对用sql脚本的版本号进行排序，并按顺序应用：

可以看到执行数据库表后在checksum中储存一个数值，用于在之后运行过程中对比sql文件执行是否有变化。

注意：

flyway在执行脚本时，会在源数据表中检查checksum值，并确定上次运行到哪一个脚本文件，本次执行时从下一条脚本文件开始执行。所以编写脚本的时候不要去修改原有的脚本内容，并且新的脚本版本号要连续

概念

版本：对数据库的每一次变更可称为一个版本。

迁移：Flyway把数据库结构从一个版本更新到另一个版本叫做迁移。

可用的迁移：Flyway的文件系统识别出来的迁移版本。

已经应用的迁移：Flyway已经对数据库执行过的迁移。 

常见问题

1、可以基于环境变量，实现不同的环境，做不同的初始化脚本吗？
 基于我们的配置中 心，可以对flyway.locations配置进行修改，不同环境的初始化脚本可以放到不同的目录下。

2、初始化数据过程会发生错误回滚？
 每 一个sql 文件会有 一个单独的事物，如果单个文件中发 生错误，单个文件的操作会回滚， 比如有1、2、3个 文件，第 二个文件发生错误，第二个文件所有操作将会回滚，第三个文件不会执行。但： Unfortunately, today only DB2, PostgreSQL, Derby, EnterpriseDB and to a certain extent SQL Server support DDL statements  inside a transaction。 所以，建议不要把ddl 文件和dml语句句放到同 一个文件 里，避免不必要的麻烦。

3、多个节点能够并行执行migration吗？
 当然可以！Flyway使用数据库锁机制（locking technology of your database）来协调多个节点，从而保证多套应用程序可同时执行migration，而且集群控制也可做配置。

Flyway提供的六种命令

命令	描述
Baseline	初始化schema_version表，并插入一条原始verion=1
Info	打印所有的迁移的信息以及状态
Validate	迁移之前进行验证
Migrate	应用所有的迁移到最新版本，它会在你的DB中新建个表schema_version来存放每次升级的版本信息
Repair	主要做了两件事，移除所有失败的迁移（升级），重置校验和删除schema_version失败记录
Clean	清除目标库所有表及数据，不可用！！！
Undo	用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴，过于机械化，一般不推荐使用。一般建议使用 模式来解决

Flyway 将 SQL 文件分为 Versioned 、Repeatable 和 Undo 三种：

Versioned：用于版本升级, 每个版本有唯一的版本号并只能执行一次.

Repeatable：可重复执行, 当 Flyway检测到 Repeatable 类型的 SQL 脚本的 checksum 有变动, Flyway 就会重新应用该脚本. 它并不用于版本更新, 这类的 migration 总是在 Versioned 执行之后才被执行。

Undo：用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴，过于机械化，一般不推荐使用。一般建议使用 Versioned 模式来解决。

集成SpringBoot

1.添加依赖

<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.1.1</version>
</dependency>

添加插件：
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.1.1</version>
</plugin>

2.Spring Boot使用Flyway参数配置

# 数据库版本控制
spring:
  flyway:
    # 启用或禁用 flyway
    enabled: true
    # 字符编码
    encoding: utf-8
    # 对执行迁移时基准版本的描述
    baseline-description: test
    # 若连接的数据库非空库，是否初始化
    # 当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.
    baseline-on-migrate: false
    # 指定 baseline 的版本号,缺省值为 1, 低于该版本号的 SQL 文件, migrate 的时候被忽略
    # 开始执行基准迁移时对现有的schema的版本打标签，默认值为1.
    baseline-version: 1
    # 是否开启校验
    # 迁移时是否校验，默认为 true
    validate-on-migrate: true
    # 默认脚本加载路径：/db/migration
    # locations: ["classpath:/db/migration"]
    # flyway 的 clean 命令会删除指定 schema 下的所有 table，默认 false
    clean-disabled: false
    # 发环境最好开启 outOfOrder, 生产环境关闭 outOfOrder
    # 是否允许无序的迁移，默认 false
    out-of-order: true
    # 检查迁移脚本的位置是否存在，默认false
    check-location: false
    # 当读取元数据表时是否忽略错误的迁移，默认false
    ignore-future-migrations: false
    # 当初始化好连接时要执行的SQL
    init-sqls: show tables;
    # 迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源
    #url:
    # 迁移数据库的用户名
    #user:
    # 目标数据库的密码
    #password:
    # 设置每个placeholder的前缀，默认${
    #placeholder-prefix:
    # 是否要被替换，默认true
    #placeholder-replacement:
    # 设置每个placeholder的后缀，默认}
    #placeholder-suffix:
    # 设置placeholder的value
    #placeholders.[placeholder name]
    # 设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema
    #schemas
    # 迁移文件的前缀，默认为V
    #sql-migration-prefix:
    # 迁移脚本的文件名分隔符，默认__
    #sql-migration-separator:
    # 迁移脚本的后缀，默认为.sql
    #sql-migration-suffix:
    # 使用的元数据表名，默认为schema_version
    #tableflyway:
    # 迁移时使用的目标版本，默认为latest version
    #target:

3.命名规范

sql 脚本存放目录:src/main/resources/db/migration

对应一个程序版本的多个脚本，从1开始，比如1.0.9版本，有多个任务：张三负责a任务（tapd号为1111111），李四负责b任务（tapd号为222222），他们的任务都涉及到db更新他们会分别创建两个脚本：

V1.0.9.0.1__1111111.sql

V1.0.9.0.2__222222.sql

说明：V大写，中间是两个下划线（）