flyway使用简介
官网https://flywaydb.org/背景Flyway是独立于数据库的应用、管理并跟踪数据库变更的数据库版本管理工具。用通俗的话讲,Flyway可以像Git管理不同人的代码那样,管理不同人的sql脚本,从而做到数据库同步。流程1、 首先配置好flyway的基本信息后,运行项目,会在数据库表中默认新建一个数据表用于存储flyway的运行信息,默认的数据库名:flyway_...
官网
背景
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大写,中间是两个下划线()
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)