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:前面两个"__"

3. 前面说了，out-of-order: true开发环境开启，生产环境关闭。
   那么关闭了，我们如何手动在生产环境迁移数据库？
   很多方法，其一是通过Maven插件命令：

mvn flyway:migrate -Dflyway.url=... -Dflyway.user=... -Dflyway.password=...

需要添加配置：-Dflyway.url=... -Dflyway.user=... -Dflyway.password=...
不然是会报错的！
执行结果：

success
至此，整合完毕！
mysql