Flyway 助力数据库脚本自动化管理攻略

原文地址：梁桂钊的博客

博客地址：http://blog.720ui.com

欢迎关注公众号：「服务端思维」。一群同频者，一起成长，一起精进，打破认知的局限性。

今天，探讨一个有趣的话题：我们可以通过 Git 来实现项目版本控制；通过 Jenkins 进行持续集成，那么对于数据库层面，我们仍然依赖于纯手工运行 SQL 脚本，对此，我们在多环境（开发环境、测试环境、预发环境、生产环境）中如何确保其 SQL 脚本的最新性和正确性？

众所周知，人工的操作非常容易出问题，我们应该让程序帮忙自动进行管理和迁移。今天，笔者推荐一款开源的数据库迁移工具 Flyway。

Flyway 不仅可以支持 MySQL，它也可以支持非常多其他的数据库。

事实上，Spring Boot 已经完美整合了 Flyway。对此，我们可以非常便捷地使用它。首先，我们引入 Maven 依赖。(注意的是，我们项目中还需要 spring-boot-starter-jdbc、 mysql-connector-java 依赖)

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

此外，我们在 application.yml 中配置相关选项。Spring Boot 默认在 classpath://db/migration 目录下扫描Migration。这里，笔者通过 spring.flyway.locations 将其调整为 db/sql。

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    locations: [classpath:db/sql]

当系统程序启动时，它会自动创建 flyway_schema_history 文件。(当然，也可以自己手动创建)。这张表是 Flyway 的元数据表， 其保存着每次 migration 的记录, 记录包含 migration 脚本的版本号和 SQL 脚本的 checksum 值。当一个新的 SQL 脚本被扫描到后, Flyway 解析该 SQL 脚本的版本号, 并和 metadata 表对比， 如果该 SQL 脚本版本更新的话, 将在指定的 DB 上执行该 SQL 文件, 否则跳过该 SQL 文件。

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`)
)

然后，我们在 db/sql 下手动创建一个初始化的 SQL 脚本：V1.1__INIT_DB.sql。

DROP TABLE IF EXISTS `tag`;

CREATE TABLE `tag` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `gmtCreate` date DEFAULT NULL,
  `gmtModified` date DEFAULT NULL,
  `title` varchar(32) DEFAULT NULL,
  `parentId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

那么，在程序再次启动后，它会将其自动化发布到数据库中。   

这里，需要补充的知识点：Flyway 的版本比较规则。其采取左对齐原则，缺位用 0 代替。例如 1.1 比 1.0 版本高，1.1.1 比 1.1  版本高，而 1.1.01 和 1.1.1  版本一致。 并且，它们会按照版本排序且顺序执行。

此外，Flyway 不仅支持 DDL，也同时支持 DML（insert、update、delete）等。因此，我们可以再创建一个 V1.2__INSERT_TAG_DATA.sql 文件来验证一下。

INSERT tag(title, parentId) values('java', 0);
INSERT tag(title, parentId) values('spring', 0);

最后，我们在来一起探讨下Flyway 支持常见类型的 migration：

• Versioned migrations：数据库升级脚本
• Repeatable migrations：可重复执行，当脚本 checksums 改变时会重新执行。

• prefix: 前缀标识，默认值 V 表示 Versioned, R 表示 Repeatable
• version: 标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点.或下划线_
• separator: 用于分隔版本标识与描述信息, 默认为两个下划线__
• description: 描述信息, 文字之间可以用下划线或空格分隔
• suffix: 后续标识, 默认为.sql

总结一下，Flyway 通过元数据（flyway_schema_history）帮忙我们自动化维护和管理数据库的版本迁移。

写在末尾

【服务端思维】：我们一起聊聊服务端核心技术，探讨一线互联网的项目架构与实战经验。让所有孤军奋战的研发人员都找到属于自己的圈子，一起交流、探讨。在这里，我们可以认知升级，连接顶级的技术大牛，连接优秀的思维方式，连接解决问题的最短路径，连接一切优秀的方法，打破认知的局限。

更多精彩文章，尽在「服务端思维」！

本文由博客一文多发平台 OpenWrite 发布！