共计 976 个字符,预计需要花费 3 分钟才能阅读完成。
最近学习新项目时,数据库使用 flyway 进行管理的,之前并没哟使用过,第一次遇到有点懵,于是了解了一下。
官方文档
简介
flyway 是一款数据库迁移工具, 在开发中,数据库需要迁移到很多不同的环境, 开发环境,测试环境,生产环境等等。
通过备份来迁移数据库,你根本不知道你现在的数据库处于哪个状态,数据库升级脚本有没有执行成功,执行到了哪一步这些信息都不知道,在代码上有 git 可以进行版本控制,但是在数据库我们却没有什么很好的方式进行数据库版本管理和迁移。
使用 flyway, 就可以跟踪数据库版本的改变,明确数据库处于那个状态,并且以确定的方式从数据库的当前版本迁移到新版本。
原理
当你使用 flyway 时,它会在数据库寻找一个历史版本的表, 一般表名是 schema_version, 如果没有 flyway 会创建这么一个表,专门用来管理数据库的版本信息。
紧接着 flyway 会扫描类路径或文件系统下面的文件,可以是 sql 文件或 java 程序,根据版本号排序并执行。
每执行一个版本时,flyway 都会在 schema_version 表中记录下这次升级,之后再执行中,对与表里已经存在的版本,下一次就不会再执行了。
通过这种方式,我们可以指定数据库的版本,并且每次数据库版本升级的信息都储存在数据库里,升级的内容是执行的 sql 文件,这样以来就可以追踪数据库版本的改变,迁移也都是自动完成。
使用中遇到的问题
一开始不熟悉 flyway,一遇到未知的问题就只能还原备份,后来我才发现,我遇到的 flyway 错误,一般都是运行的 sql 文件会与数据库已经确立的结构冲突,flyway 遇到这种错误情况,就取消这次版本的升级,并且记录这次版本升级失败。
比如当我执行这个 1.3.0 的数据库升级, 想要在 apply 表中添加一个 check_status 字段:
但是执行时却失败了,控制台的报错是这样的:
它明确的告诉了失败的原因,错误 sql 脚本的位置、语句等,可惜我之前都没注意到。
这里的失败是 apply 已经有一列 check_status 了,所以再添加一列相同的字段就会出错。可以把 apply 的这个字段删除就成功通过了。
在 schema_version 表中明确记录这次执行是失败的,success 字段为 0.
这样出错了就可以去查看排除,而不是一味地还原数据库了。
总结
现在有越来越多强大的工具,合理运用可以帮助我们开发。