iOS开发JAVASpring

数据库迁移工具Flyway

Posted Cola🌀

前言

不知道你有没有遇到过这种场景，一套代码部署在不同的环境中，随着时间的过去，各个环境代码有版本差异，代码层面可以通过不同的版本来控制，但是数据库层面经常容易忘记更新！

比如刚开始环境 A 和环境 B 的代码版本是一样的，但是随着版本的迭代，环境 A 的系统一直持续迭代，但是环境 B 的系统由于种种原因没有升级，一直保持在最初的版本。如果某个时候需要对环境 B 的系统进行升级的话，你会发现，中间已经过了好多个版本，各个版本的差距很大，数据库结构有调整，不能直接打包发布，需要把之前所有对环境 A 调整的 SQL 都在环境 B 中执行一遍才行。

这个时候如果 SQL 版本做的好的问题不大，依次执行就行了，但是如果中间有人员离职或者记录缺失，那只能通过对比数据库结构来进行解决了。

数据迁移

前面我们的提到的场景专业的名词叫数据迁移，那为什么会出现数据迁移的场景呢？我从官网截了一张图大家可以看下，虽然说可能跟我实际开发不是一样，但是也差不多类似会出现这种场景，存在多个环境。可以看到虽然我们的代码可以通过版本迭代来控制，但是我们的数据库却不行，很多时候连脚本是否执行过都会忘记，这种事情光靠人记是很难的。

Flyway

Flyway是一款数据库迁移工具，它让数据库迁移变得更加简单。它能像Git一样对数据库进行版本控制，支持命令行工具、Maven插件、第三方工具（比如SpringBoot）等多种使用方式。

不管是在开发过程中还是在线上，数据库结构都是经常变化的，很多情况下都需要对数据库的变化做跟踪和管理，Flyway就是这样一款管理工具。

在Flyway里，每次数据库变化都称为一次迁移，每次迁移都有一个版本号。Flyway会在数据库里存储当前处在哪个版本。每当需要上线的时候，你可以手动或者自动地将代码里的多个迁移，同步到数据库当中。

如图所示，文件名以V开头，后面跟上版本号，然后是两个下划线，最后是对此次迁移的描述，用下划线或者空格隔开。在每个sql文件中，都可以写多个DDL语句或者CRUD语句，根据你的需求而定。

怎么才能触发迁移呢？Flyway提供了多种方式：

在Spring Boot中使用。Spring Boot自带对Flyway的支持，如果你的项目引入了Flyway的依赖，Spring Boot会自动将其配置好。Flyway的默认迁移文件路径是上图里的类路径 db/migration 。相对于前两种方式，使用API可以不用安装命令行工具，不用新建配置文件（使用Spring Boot的配置文件），同时他还可以利用项目里的DataSource对象，做到了开箱即用。

工作原理

使用Flyway时我们需要编写好数据库迁移的SQL脚本，比如V1__Initial_Setup.sql中初始化了三种表，V2__First_Changes.sql中又新增了两种表。Flyway会创建flyway_schema_history表，用于存储这些SQL脚本的执行情况，从而对数据库进行版本控制。当我们使用Flyway进行数据库迁移时，Flyway会根据flyway_schema_history表中的记录，自行决定需要执行哪些SQL脚本，从而实现数据库迁移。

接入了 Flyway 过后，在数据库中会生成一张默认名为​​flyway_schema_history​​​ 的数据表，用来追踪数据库的变化。程序启动的时候 Flyway 都会在文件系统或者 classpath 路径下面寻找迁移脚本。每个迁移脚步都有相应的命名规则，Flyway 会根据文件的版本号进行迁移，每次迁移过后都会在​​flyway_schema_history​​ 表中插入一条类似如下的记录，记录版本已经对应的脚本文件和校验码等信息：

每次启动的时候只会执行最高版本的脚本，而且如果版本没变，脚本变了是启动不了的。

脚本命名规范

为了能被Flyway正确执行，SQL迁移脚本需要遵循如下规范：

  • Prefix（前缀）：V表示有版本号的数据库迁移，U表示一些数据库版本的回滚，R表示可重复执行的数据库迁移；
  • Version（版本号）：Flyway会按照版本号的大小顺序来执行数据库迁移脚本；
  • Separator（分隔符）：命名时使用双下划线分隔符；
  • Description（描述）：用于描述该迁移脚本的具体操作说明；
  • Suffix（后缀）：表示.sql文件。

相关命令

  • migrate：将schema更新到最新的版本并且如果不存在flyway_schema_history表就会创建一个。它是flyway工作流程的核心。它将扫描文件系统或您的类路径以获取可用的迁移。它将它们与已应用于数据库的迁移进行比较，如果发现任何差异，它将迁移数据库以缩小差距。
  • clean：删除数据库中所有的表，千万别在生产环境上使用。删除已配置的schema中所有对象，当然，不要对生产DB操作，毕竟有点类似删库跑路。。。
  • info：打印所有的Migration的信息，包含状态，通过info可以知道哪些Migration已经应用了，哪些处于pending状态。
  • validate：验证将要更新的migrations是否与已更新的migration有冲突，有点类似于代码合并时git会检查是否有冲突。
  • undo：撤消最近应用的版本迁移。可指定撤销的最终版本。
  • baseline：相对于Migrate来说，它不再是从最初开始迁移，而是先将某数据库作为基准线，然后迁移相对此数据库还未更新的migrations。
  • repair：修复flyway_schema_history表。

SpringBoot 项目接入 Flyway

SpringBoot 项目接入 Flyway 非常简单，主要分为如下几步即可，我们依次来看一下。

加入依赖(在项目 pom.xml 文件中加入上面的依赖即可。)

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

增加配置

# 启用 flyway
spring.flyway.enabled=true
# 禁止清理数据表
spring.flyway.clean-disabled=true
# 是否已经有数据库
spring.flyway.baseline-on-migrate=true
# 基础版本号，依次递增
spring.flyway.baseline-version=0
# 迁移脚本的存放的位置
spring.flyway.locations=classpath:db/migration

这里因为很多情况下我们并不是一个新项目就开始使用 Flyway，而是项目在迭代中才引入的，所以上面的配置​​spring.flyway.clean-disabled=true​​ 一定要禁用。上面几个配置由于已经继承到 SpringBoot 中了所以配置起来十分简单。

迁移脚本文件

脚本的命名规则按照上面说的，我们这边采用版本迁移。我们创建一个版本的 SQL 文件放到对应的类路径文件夹里面，文件名叫V1.2__create_test_table.sql，文件内容如下，然后我们启动项目。

CREATE TABLE `test_table`  (
  `id` int(11) NULL COMMENT 'ID',
  `name` varchar(255) NULL COMMENT 'Name'
);

启动过程中我们看到如下日志，显示了当前的版本，以及迁移的版本。

我们再查看数据库，首先 test_table 已经创建成功了

另外我们在查看flyway_schema_history 表，会发现已经多了一条版本数据，至此我们介入 Flyway 已经成功了。