数据库版本管理： Flyway 探索与实践

引言： 如果你是一个独立开发者或者不需要维护多个系统，那么维护数据库版本并不复杂。但是如果你的团队正在快速迭代或者同时开发多个功能，在多个环境版本并行，在多个生产服务器上部署你的服务，那么数据库的管理将变成一件麻烦事。如何更新所有的数据库，并维护好所有的更新记录，把多个人的操作合并起来带来了挑战。 我们团队在开发的过程中也有同样的困扰。这篇文章将介绍我们团队是如何通过 Flyway 将这些问题逐一解决。

flyway 基本概念

什么是 flyway，为什么要用 flyway

flyway 是数据库版本控制管理工具，用于进行 sql 脚本版本控制和数据库迁移。

以前我们的数据库更改都是通过在某一个文件夹中添加一条 sql 文件，然后手动执行的。

这样在一个新环境进行数据库迁移时就会衍生出一系列的问题：

•需要人工手动一条一条地执行这些脚本 •有些时候，不恰当的命名会使这些 sql 脚本的执行顺序变得难以确定 •如果手动执行时，脚本执行一半发生了一些其他的事情中断了执行人的操作，那么在下次执行时怎么知道当前数据库的 sql 执行到哪里了，哪些成功执行了哪些没有执行成功

所以我们迫切地需要一个工具来处理这些问题——flyway

flyway 是如何工作的

flyway 会在项目启动时，完成建立数据库连接池后自动执行如下操作：

1.如果数据库是一个空的数据库，flyway 会创建一个名为 flyway_schema_history 的 sql 执行记录表，如果不是一个空的数据库，flyway 会跳过这一步 2.flyway 会扫描项目指定路径下（ spring 项目默认在 classpath:db/migration 下）的所有 sql 脚本，并和 flyway_schema_history 表下所有的脚本记录进行比对，所有版本号小于或者等于当前版本的脚本将被忽略。但是 flyway 会计算这些脚本的校验和，然后和数据库记录执行过的脚本比较，如果他们校验和不一致就会报错并停止项目执行 3.其余的所有脚本将会按照版本号进行排序，然后逐个执行

补充：

如果一条 sql 脚本执行出错，flyway 会在数据库中留下一条执行出错的记录，并且这条脚本的执行将被自动回滚。版本号高于出错脚本的待执行脚本将都不会被执行，也不会留下记录

WARNING: 如果 flyway 记录表中有出错记录，那么 flyway 将无法执行，请手动更改脚本错误，并手动删除记录表中的这条出错记录重新启动项目。

如何使用 flyway

前提：

假设数据库连接池等相关配置已经设置完毕，如果没有可以参考 Alibaba Druid 配置

1.导包

2.添加配置

#开启 flyway，flyway 默认为 true, 所以不设置其实也行 spring.flyway.enabled=true

一些其他的可选配置(其实用默认的就行，这些都可以不写)

spring.flyway.tableflyway flyway 记录表在数据库中的名字，默认是 flyway_schema_history spring.flyway.baseline-description 对执行迁移时基准版本的描述. spring.flyway.baseline-on-migrate 当迁移时发现目标 schema 非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认 false. spring.flyway.baseline-version 开始执行基准迁移时对现有的 schema 的版本打标签，默认值为 1. spring.flyway.check-location 检查迁移脚本的位置是否存在，默认 false. spring.flyway.clean-on-validation-error 当发现校验错误时是否自动调用 clean，默认 false. spring.flyway.encoding 设置迁移时的编码，默认 UTF-8. spring.flyway.ignore-failed-future-migration 当读取元数据表时是否忽略错误的迁移，默认 false. spring.flyway.init-sqls 当初始化好连接时要执行的 SQL. spring.flyway.locations 迁移脚本的位置，默认 db/migration. spring.flyway.out-of-order 是否允许无序的迁移，默认 false. spring.flyway.password 目标数据库的密码. spring.flyway.placeholder-prefix 设置每个 placeholder 的前缀，默认${. spring.flyway.placeholder-replacementplaceholders 是否要被替换，默认 true. spring.flyway.placeholder-suffix 设置每个 placeholder 的后缀，默认}. spring.flyway.placeholders.[placeholder name]设置 placeholder 的 value spring.flyway.schemas 设定需要 flywary 迁移的 schema，大小写敏感，默认为连接默认的 schema. spring.flyway.sql-migration-prefix 迁移文件的前缀，默认为 V. spring.flyway.sql-migration-separator 迁移脚本的文件名分隔符，默认__ spring.flyway.sql-migration-suffix 迁移脚本的后缀，默认为.sql spring.flyway.tableflyway 使用的元数据表名，默认为 schema_version spring.flyway.target 迁移时使用的目标版本，默认为 latest version spring.flyway.url 迁移时使用的 JDBC URL，如果没有指定的话，将使用配置的主数据源 spring.flyway.user 迁移数据库的用户名 spring.flyway.validate-on-migrate 迁移时是否校验，默认为 true

3.建立 sql 脚本

默认配置下 flyway 的脚本在 resources/db/migration 下

命名格式为 V {describe}.sql

4.执行项目即可

常见问题

如何中途集成 flyway

问题描述

•flyway 集成的最佳时期是项目刚开始时，将数据库初始化脚本等全权交由 flyway 来管理。 •其次就是在项目起步不久，项目的 sql 脚本还尚且有序，且清楚当前脚本执行到哪里时。

幸运的是，我们当时集成 flyway 时就处于第二种阶段。那么到底如何集成呢，有什么该注意的呢

解决方案

1.按照如何使用下的第三条给脚本命名 2.在数据库中执行如下脚本建立 flyway 记录表(这里用的数据库是 mysql 8.0)

use ${数据库名字}; DROP TABLE IF EXISTS flyway_schema_history; CREATE TABLE flyway_schema_history ( installed_rank int(11) NOT NULL, version varchar(50) DEFAULT NULL, description varchar(200) NOT NULL, type varchar(20) NOT NULL, script varchar(1000) NOT NULL, checksum int(11) DEFAULT NULL, installed_by varchar(100) NOT NULL, installed_on timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, execution_time int(11) NOT NULL, success tinyint(1) NOT NULL, PRIMARY KEY (installed_rank), KEY flyway_schema_history_s_idx (success) ) ENGINE=${数据库引擎} DEFAULT CHARSET=utf8;

3.向 flyway 记录表插入手动插入已执行过 sql 脚本的记录

INSERT INTO flyway_schema_history (installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success) VALUES (1, ${version}, ${describe}, 'SQL', ${script name}, ${script checksum}, ${db user}, '2019-12-03 20:41:26', 131, 1),(...);

4.处理 flyway 的校验和

以下两种方法选择一种即可

•手动关闭 flyway 的 checksum 校验，只需要在配置中添加这么一条即可：

spring.flyway.validate-on-migrate=false

•使用 flyway 提供的 cli 工具，执行 repair 命令

详细下载和使用请参考下载和使用 Command-line tool

在当前一周 alpha，下一周上线的开发模式下如何正确使用 flyway

问题描述

考虑以下流程：

1.我们这周新切出的 alpha 分支即 fat 环境 flyway 的版本为 V10，master 分支（ dev 环境）也是 V10 2.之后 master 分支开发了新功能涉及到修改数据库，版本号变为了 V11 3.fat 环境出现了 bug，需要修改数据库，创建了一个版本号为 V12 的脚本，修改也整合到了 master 上

于是现在 dev 环境的脚本记录是 V10, V11, V12; fat 环境的脚本记录是 V10，V12

等下周 master 又切出新的 alpha 分支，虽然这个分支的代码携带了 V10, V11, V12,三个脚本，但是由于 fat 数据库的最新脚本记录是 V12，所以 V11 这个脚本将永远不会被执行

解决方案

我想到的方法有三种：

1.防范于未然，一般情况下，fat 出现需要修改数据库的 bug 在 dev 环境下自己单元测试的时候就应该能发现。不应该在 fat 环境被测试测出来了才发现这个问题。

2.新建 fat 环境的 sql 执行脚本时，把 master 分支中新脚本版本号之前但是不在 alpha 版本的脚本全部 copy 过来执行。

这种方法适用于确定 copy 过来的其他脚本不会影响到 fat 正常运行的情况

3.将新脚本版本号提前，提前到切出当前 alpha 分支时的脚本版本号之后。

WARNING: 使用这个方法时要注意，dev 环境需要手动跑这条新脚本，并在 flyway 执行记录数据库中手动插入这条执行记录

Reference

flyway 官方网站: https://flywaydb.org/

点击应聘 Java 开发工程师、后端开发工程师、前端开发工程师等职位： https://www.liepin.com/company/10037071/

更多相关信息，欢迎访问我们的官网 https://www.graviti.cn ，或关注我们的微信服务号 Graviti 。

商务合作邮箱： [email protected]

人才招聘邮箱： [email protected]