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表中的执行数据并更新脚本重新执行