如果你是一个独立开发者或者不需要维护多个系统,那么维护数据库版本并不复杂。但是如果你的团队正在快速迭代或者同时开发多个功能,在多个环境版本并行,在多个生产服务器上部署你的服务,那么数据库的管理将变成一件麻烦事。如何更新所有的数据库,并维护好所有的更新记录,把多个人的操作合并起来带来了挑战。
我们团队在开发的过程中也有同样的困扰。这篇文章将介绍我们团队是如何通过Flyway将这些问题逐一解决。
flyway是数据库版本控制管理工具,用于进行sql脚本版本控制和数据库迁移。以前我们的数据库更改都是通过在某一个文件夹中添加一条sql文件,然后手动执行的。这样在一个新环境进行数据库迁移时就会衍生出一系列的问题:
所以我们迫切地需要一个工具来处理这些问题——flyway
flyway会在项目启动时,完成建立数据库连接池后自动执行如下操作:
补充:
如果一条sql脚本执行出错,flyway会在数据库中留下一条执行出错的记录,并且这条脚本的执行将被自动回滚。版本号高于出错脚本的待执行脚本将都不会被执行,也不会留下记录
WARNING: 如果flyway记录表中有出错记录,那么flyway将无法执行,请手动更改脚本错误,并手动删除记录表中的这条出错记录重新启动项目。
前提:假设数据库连接池等相关配置已经设置完毕,如果没有可以参考Alibaba Druid配置
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>6.1.0</version>
</dependency>
# 开启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
默认配置下flyway的脚本在resources/db/migration下
命名格式为V{describe}.sql
问题描述
幸运的是,我们当时集成flyway时就处于第二种阶段。那么到底如何集成呢,有什么该注意的呢
解决方案
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;
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),(...);
以下两种方法选择一种即可
spring.flyway.validate-on-migrate=false
详细下载和使用请参考下载和使用Command-line tool
问题描述
考虑以下流程:
于是现在dev环境的脚本记录是V10, V11, V12; fat环境的脚本记录是V10,V12
等下周master又切出新的alpha分支,虽然这个分支的代码携带了V10, V11, V12,三个脚本,但是由于fat数据库的最新脚本记录是V12,所以V11这个脚本将永远不会被执行
解决方案
我想到的方法有三种:
这种方法适用于确定copy过来的其他脚本不会影响到fat正常运行的情况
WARNING: 使用这个方法时要注意,dev环境需要手动跑这条新脚本,并在flyway执行记录数据库中手动插入这条执行记录