Flyway 数据库版本管理工具操作指南

FlyWay

1、什么是 Flyway ？

  Flyway 是一款开源的数据库版本管理工具，它更倾向于规约优于配置的方式。Flyway可以独立于应用实现管理并跟踪数据库变更，支持数据库版本自动升级，并且有一套默认的规约，不需要复杂的配置，Migrations 可以写成 SQL 脚本，也可以写在 Java 代码中，不仅支持 Command Line 和 Java API，还支持 Build 构建工具和 Spring Boot 等，同时在分布式环境下能够安全可靠地升级数据库，同时也支持失败恢复等。
  简单来说，Flyway 可以管理每一次操作的 DDL 语句及某些 DML 语句，来记录当前数据库的最新结构状态。因此来作为一个数据库版本管理的工具。
更多请参照： Flyway官网

2、为什么要用Flyway

  结合当前的线上、测试环境等数据库结构，以及当前的需求迭代速度。需要一个整理数据库版本的工具来统一认知与进度。不至于 A 改了数据库但是 B 不知道，导致 B 做需求提交的时候不知道数据库的变更，将时间与效率浪费在了不必要的地方。同时也是对数据库迁移历史信息有一定的认知，知道哪些需求迁移了数据库结构。
同时用 Flyway 可以保存最新的数据库结构，同时利用一定条件的 DML 语句可以方便我们随时能够模拟一个相同环境的测试数据库环境。

3、Flyway的工作原理及规则

简单的介绍一下 Flyway 工作原理
  例如你用 Flyway 指向了一个空数据库，Flyway 将会创建一个 flyway_schema_history 为默认名的表，了、以此来跟踪数据库的状态。

  根据版本号对迁移进行排序并按顺序应用，紧接着 Flyway 将会开始扫描文件系统或应用程序的类路径以进行迁移。文件可以用 Sql 或 Java 编写。然后根据版本号逐步对数据库进行迁移。

  随着每次迁移的应用，架构历史记录表会相应地更新。Flyway 总是会根据版本号排序并且按顺序执行，Flyway 不会执行比当前版本小的语句。所以每次需要演化数据库时，无论是结构 (DDL) 还是参考数据 (DML)，只需创建一个版本号高于当前版本号的新迁移信息。下次执行时，Flyway 会找到它并相应地升级数据库。
  同时 Flyway 是不支持降级处理的，哪怕你之前用了一个建表的脚本，后来觉得脚本没用了，也不能进行删除，要删除表的话也只能通过新的sql脚本才能删除。Flyway的版本只能是往上走的，并且历史迁移记录不能动。

4、Flyway的部署及实践

• 实践一：本地命令行操作
  通过官方下载（ https://flywaydb.org/download）命令行压缩包并解压到对应路径
  在当前项目结构比较稳定时，导出数据库当前结构。
  在本地flyway安装目录中找到conf/flyway.conf配置文件，进行数据库内容配置，在flyway/sql中 配置数据库初始化语句，之后配置flyway环境变量后，使用flyway migrate命令初始化数据库。

• 实践二：Docker 容器部署操作
  通过 docker 拉取 Flyway 官方镜像，完成后。
  假如是在本机操作的话，我们可以使用挂载目录的方式，使用-v将本地目录挂载到容器内部配置进行执行，例如：

docker run -d 
-v /Users/mayang/Downloads/flyway-8.0.0-beta1/sql:/flyway/sql 
-v /Users/mayang/Downloads/flyway-8.0.0-beta1/conf:/flyway/conf 
-v /Users/mayang/Downloads/flyway-8.0.0-beta1/jars:/flyway/jars 
flyway/flyway info

-v 为本地挂载路径

   挂载后会根据本地目录进行执行，所以只需要共享配置文件，对于之后的修改都放在公共配置文件中，那么就可以统一操作flyway了。解决了本地命令行只能一个人操作的麻烦。
Docker文档：https://github.com/flyway/flyway-docker

当然也有代码执行的方式，但是将DSL与DML语句写在项目中可能并不优雅。

5、Flyway主要操作介绍

• Migrate
  迁移操作，对于每次数据库进行版本迁移的操作。将sql脚本中的内容进行执行记录。
• Clean
  删除配置架构中的所有结构及数据。（应该在配置中禁止该操作。）
• Info
  打印数据库已有的迁移信息以及状态
• Validate
  根据可用的迁移验证已有的迁移。
• Undo
  回滚操作，但是对于直接使用Undo比较机械，建议是选择回滚版本TargetVersion进行操作。（社区版不可用，需要pro版）
• Baseline
  初始化 schema_version 表，并插入一条原始 version = 1 。
  相对于 Migrate 来说，它不再是从最初开始迁移，而是先将某数据库作为基准线，然后迁移相对此数据库还未更新的 migrations。比如对于某个已存在结构的数据库刚开始使用 flyway
• Repair
  删除失败的迁移条目（仅适用于不支持 DDL 事务的数据库）
  将应用迁移的校验和、描述和类型与可用迁移的校验和、描述和类型重新对齐
  将所有丢失的迁移标记为已删除

6、线上服务迁移方案

1. 线上项目 Flyway 操作方案

    使用baseline操作将当前版本作为数据库初始化版本。
    同时将1.0.0版本内放入当前数据库初始化结构的sql语句

2. 线上数据库后续迁移

Flyway 中定义的迁移便是每一次数据库结构的变化。
根据当前情况采用方案二，项目的结构变化通过提交需要更改结构的 DDL 需求语句，提 DBA 进行review，等待迁移脚本审核过后，管理版本后并且使用 Flyway 容器执行迁移命令。（根据实际情况调整）

3. 数据库 Flyway 回滚方案

• 利用官方操作 Undo() 进行回滚操作
• 先使用 clean 操作后删除对应文件后再用 migrate 操作（数据会清空，禁用生产环境），在测试环境有固定的 DML 添加测试数据操作的话可以使用。
• 在每次执行迁移操作之前，准备好一份备份操作sql脚本，等待需要回滚操作的时候，使用flyway migrate来执行新版本回滚操作。

7、项目迁移规则

1. 版本值规则

• 1.0.1.1 比 1.0.1 版本高。
• 1.0.10 比 1.0.9.4 版本高。
• 1.0.10 和 1.0.010 版本号一样高, 每个版本号部分的前导 0 会被忽略。

2. Flyway文件规则

• Versioned 用于版本升级, 每个版本有唯一的版本号并只能执行一次.
• Repeatable 可重复执行, 当 Flyway检测到 Repeatable 类型的 SQL 脚本的 checksum 有变动, Flyway 就会重新应用该脚本. 它并不用于版本更新, 这类的 migration 总是在 Versioned 执行之后才被执行。
• Undo 用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴，过于机械化，一般不推荐使用。一般建议使用 Versioned 模式来解决。

3. 文件命名规则

• Prefix 可配置，前缀标识，默认值 V 表示 Versioned, R 表示 Repeatable, U 表示 Undo
• Version 标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点 . 或下划线 _
• Separator 可配置, 用于分隔版本标识与描述信息, 默认为两个下划线 __
• Description 描述信息, 文字之间可以用下划线 _ 或空格 分隔
• Suffix 可配置, 后续标识, 默认为 .sql
  例如：
  V1.0.1__port-service_register_developer_createUser.sql （代表Versioned类型，版本为1，描述为CreateUserTable）
  命名尽量采用格式
  V1.0.1__ProjectName_{Feature|fix}_Developer_Description.sql

8、参考文档

Flyway简介：https://blog.csdn.net/chenleiking/article/details/80691750