[ Flyway ] dataMigration 01
作者:互联网
Database Migration Tools
数据库修改/历史数据迁移到新表/数据库实例的切换
手动执行的问题: security/conflict/数据库环境隔离/环境问题
1.1 Flyway
Version control for your database
1.1.1 脚本类型
按照文件名进行分类:
-
v数字__Add_new_table
: versioned migrations 升级脚本,只执行一次,成功后不能修改 -
r数字__Add_new_table
: repeatable migrations 可重复执行,执行成功后可以修改,修改后会再次执行
eg: v1__description, r1__description , flyway_schema_history会通过名称来分割出类型、版本、描述创建到表中
脚本执行后,数据库中会创建一张新表 flyway_schema_history用来记录对数据库的操作。
1.2 基本命令
先在build.gradle
文件中配置flyway的插件,然后在此配置中加上flyway对数据库的配置信息。 在resource文件夹下创建文件夹db.migration,用来放置flyway脚本。
plugins {
id "org.flywaydb.flyway" version "..."
}
flyway {
url='...'
user='...'
password='...'
}
1.2.1 使用./gradlew flywayMigrate -i
来执行新的配置文件
1.2.2 ./gradlew flywayInfo
展示每一个脚本的分类,版本,描述和状态
1.2.3 ./gradlew flywayValidate
展示当前对数据库的操作和flyway的配置文件的哈希值有什么不同
1.2.4 ./gradlew flywayBaseline
把当前数据库init为由flyway管理的数据库,类似于git init
但是当初始化为flyway托管之后,新添加的flyway脚本需要修改为v2开始,baseline的版本为1,并且计算哈希值的checksum为null,当有v1脚本时无法进行对比计算。
12.5 ./gradlew flywayRepair
当前: 有v1, v2执行成功;v3写错了但flywayMigrate的时候build failed,
做:修改了v3 为正确的脚本再migrate的时候依然会执行不成功,因为checksum值不同。
可以:可以repair之后再执行修改后的migrate命令。repair相当于先清空v3的第一次执行记录,并更新有变化的脚本信息如checksum(在flyway_schema_history表中)
推荐手动删除 drop 表中的最后一条数据(通过version号)
1.2 Strategy
-
执行脚本后想修改脚本的方法: 新增一个补丁
-
与服务器中的版本冲突: 拉去代码前检查服务器中其他人新增的版本号,解决冲突
-
本地数据库和开发环境测试数据库类型/版本号尽量保持一致
-
保持脚本的原子性,如果一个脚本中两条数据,一条成功一条失败,建议自己手动删除第一条脚本的执行结果,删除flywayHistory表中的执行数据并更新脚本重新执行
标签:脚本,01,1.2,数据库,gradlew,flyway,Flyway,dataMigration,执行 来源: https://www.cnblogs.com/Roy2048/p/16493570.html