SpringBoot的数据库迁移之如何使用Flyway

#Flyway:数据库迁移
有什么好处
1.方便团队协作
2. 开发环境和生产环境的数据库结构统一(随着项目的进行,肯定有数据库结构的变动)

操作命令

  • Clean: 删除所有创建的数据库对象, 包括用户、表、视图等. 注意不要在生产库上执行 clean 操作.
  • Migrate: 对数据库依次应用版本更改.
  • Info: 获取目前数据库的状态. 那些迁移已经完成, 那些迁移待完成. 所有迁移的执行时间以及结果.
  • Validate: 验证已 Apply 的脚本是否有变更, Flyway 的 Migration 默认先做 Validate.
  • Baseline: 根据现有的数据库结构生成一个基准迁移脚本.
  • Repair: 修复命令尽量不要使用, 修复场景有:`
    • 移除失败的 migration 记录.
    • 已经应用的 SQL 脚本被修改, 我们想重新应用该 SQL 脚本.

#接下来在项目中集成Flyway
添加pom依赖

<!-- https://mvnrepository.com/artifact/org.flywaydb/flyway-maven-plugin-->
<plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>6.2.3</version>
</plugin>

maven插件命令:

mvn flyway:migrate

#工作原理

  • flyway 需要在 DB 中先创建一个 metdata 表 (缺省表名为 flyway_schema_history), 在该表中保存着每次 migration 的记录, 记录包含 migration 脚本的版本号和 SQL 脚本的 checksum 值.
  • 当一个新的 SQL 脚本被扫描到后, Flyway解析该 SQL 脚本的版本号, 并和 metadata 表已 apply 的的 migration 对比, 如果该 SQL 脚本版本更新的话, 将在指定的 DB 上执行该 SQL 文件, 否则跳过该 SQL 文件.

两个 flyway 版本号的比较, 采用左对齐原则, 缺位用 0 代替. 举例如下:
1.2.9.4 比 1.2.9 版本高.
1.2.10 比 1.2.9.4 版本高.
1.2.10 和 1.2.010 版本号一样高, 每个版本号部分的前导 0 会被忽略.
Flyway SQL 文件可以分为两类: Versioned 和 Repeatable.
Versioned migration 用于版本升级, 每个版本有唯一的版本号并只能 apply 一次.
Repeatable migration 是指可重复加载的 migration, 一旦 SQL 脚本的 checksum 有变动, flyway 就会重新应用该脚本. 它并不用于版本更新, 这类的 migration 总是在 versioned migration 执行之后才被执行.

默认情况下, Migration SQL的命名规则如下图:
Migration Sql

其中的文件名由以下部分组成,除了使用默认配置外,某些部分还可自定义规则.

  • prefix: 可配置,前缀标识,默认值 V 表示 Versioned, R 表示 Repeatable
  • version: 标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点.或下划线_
  • separator: 可配置, 用于分隔版本标识与描述信息, 默认为两个下划线__
  • description: 描述信息, 文字之间可以用下划线或空格分隔
  • suffix: 可配置, 后续标识, 默认为.sql

flyway 的 metadata 表结果如下:

CREATE TABLE  flyway_schema_history
    (
        installed_rank INT NOT NULL,
        version VARCHAR(50),
        description VARCHAR(200) NOT NULL,
        type VARCHAR(20) NOT NULL,
        script VARCHAR(1000) NOT NULL,
        checksum INT,
        installed_by VARCHAR(100) NOT NULL,
        installed_on TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        execution_time INT NOT NULL,
        success TINYINT(1) NOT NULL,
        PRIMARY KEY (installed_rank),
        INDEX flyway_schema_history_s_idx (success)
    )
    ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

flyway核心包:(flyway 其实仅依赖 spring-boot-starter-jdbc 包)

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

flyway配置信息:

spring:
  ## 设定 flyway 属性
  flyway:
    #    flyway 的 clean 命令会删除指定 schema 下的所有 table, 杀伤力太大了, 应该禁掉.
    clean-disabled: true
    #    禁用/启用flyway
    enabled: true
    #    设定 SQL 脚本的目录,多个路径使用逗号分隔, 比如取值为 classpath:db/migration,filesystem:/sql-migrations
    locations: classpath:db/migration
    #    如果指定 schema 包含了其他表,但没有 flyway schema history 表的话, 在执行 flyway migrate 命令之前, 必须先执行 flyway baseline 命令.
    baseline-on-migrate: true
    #    指定 baseline 的版本号,缺省值为 1, 低于该版本号的 SQL 文件, migrate 的时候被忽略.
    baseline-version: 1
    #    sql文件编码
    encoding: UTF-8
    #    设定 flyway 的 metadata 表名, 缺省为 flyway_schema_history
    table: flyway_schema_history_myapp
    #    开发环境最好开启 outOfOrder, 生产环境关闭 outOfOrder . 
    out-of-order: true

开始使用
1.在resources/db/migration 新建SQL文件
2. SQL文件名是:
V0.0.1__init_table.sql
V0.0.2__add_column.sql
tips:前面两个"__"

  1. 前面说了,out-of-order: true开发环境开启,生产环境关闭。
    那么关闭了,我们如何手动在生产环境迁移数据库?
    很多方法,其一是通过Maven插件命令:
mvn flyway:migrate -Dflyway.url=... -Dflyway.user=... -Dflyway.password=...

需要添加配置:-Dflyway.url=… -Dflyway.user=… -Dflyway.password=…
不然是会报错的!
执行结果:
success
至此,整合完毕!
mysql

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值