Spring Boot 数据库版本管理入门
1. 概述
在我们的认知中，我们会使用 SVN 或 Git 进行代码的版本管理。但是，我们是否好奇过，数据库也是需要进行版本管理的呢？
在每次发版的时候，我们可能都会对数据库的表结构进行新增和变更，又或者需要插入一些初始化的数据。而我们的环境不仅仅只有一套，一般来说会有 DEV、UAT、PRED、PROD 四套环境，会对应 DEV、UAT、PROD 三个数据库。
PRED 环境，一般连接 PROD 数据库，做准生产的验收。
那么，就意味着我们需要对 DEV、UAT、PROD 数据库都做一遍操作。“人，是系统最大的 BUG”。很多时候，我们并不能保证像机器一样，每次都操作都正确，这就导致在不同的环境下，因为数据的每个版本的初始化，带来额外的验收成本。
甚至说，因为我们常常是手动操作 DEV 数据库，没有整理一个完整清单，保证我们在 UAT、PROD 数据库中执行相同的操作。
基于以上种种，如果我们能像管理代码版本一样，来管理我们的数据库版本，是不是这些问题可以得到很好的解决？答案是，绝大多数是的。
目前，技术社区已经提供了很多解决方案。例如说：
- Flyway
- Liquibase
- dbdeploy
- SQL Source Control
- dbv
- MyBatis Migrations
在 Spring Boot 项目中，提供了对 Flyway 和 Liquibase 的内置支持，所以在有数据库版本的需求时，肯定是推荐它们两。
本文，我们会对 Flyway 和 Liquibase 进行入门学习。这样，我们在学习它们的同时，可以有比较直观的使用感受，方便后续我们对它们进行选型。
2. Flyway
示例代码对应仓库：lab-20-database-version-control-flyway 。
在 Flyway 的官网 https://flywaydb.org/ 中，对自己的介绍是：
Version control for your database.
数据库的版本管理。
Flyway 支持的数据库，主要是关系数据库。如下图所示：
Flyway 提供了 SQL-based migrations 和 Java-based migrations 两种数据库变更方式。
- 前者使用简单，无需编写 Java 代码。
- 后者需要使用 Java 编写代码，胜在灵活。
一般情况下，如果是做表的变更，或者记录的简单插入、更新、删除等操作，使用 SQL-based migrations 即可。
复杂场景下，我们可能需要关联多个表，则需要通过编写 Java 代码，进行逻辑处理，此时就是和使用 Java-based migrations 了。
下面，让我们来使用它们二者，更好的体会它们的区别。
2.1 引入依赖
在 pom.xml 文件中，引入相关依赖。
org.springframework.boot
spring-boot-starter-parent
2.1.3.RELEASE
4.0.0
lab-20-database-version-control-flyway
org.springframework.boot
spring-boot-starter-jdbc
mysql
mysql-connector-java
5.1.48
org.flywaydb
flyway-core
2.2 应用配置文件
在 resources 目录下，创建 application.yaml 配置文件。配置如下：
spring:
# datasource 数据源配置内容，对应 DataSourceProperties 配置属性类
datasource:
url: jdbc:mysql://127.0.0.1:3306/lab-20-flyway?useSSL=false&useUnicode=true&characterEncoding=UTF-8
driver-class-name: com.mysql.jdbc.Driver
username: root # 数据库账号
password: # 数据库密码
# flyway 配置内容，对应 FlywayAutoConfiguration.FlywayConfiguration 配置项
flyway:
enabled: true # 开启 Flyway 功能
cleanDisabled: true # 禁用 Flyway 所有的 drop 相关的逻辑，避免出现跑路的情况。
locations: # 迁移脚本目录
- classpath:db/migration # 配置 SQL-based 的 SQL 脚本在该目录下
- classpath:cn.iocoder.springboot.lab20.databaseversioncontrol.migration # 配置 Java-based 的 Java 文件在该目录下
check-location: false # 是否校验迁移脚本目录下。如果配置为 true ，代表需要校验。此时，如果目录下没有迁移脚本，会抛出 IllegalStateException 异常
url: jdbc:mysql://127.0.0.1:3306/lab-20-flyway?useSSL=false&useUnicode=true&characterEncoding=UTF-8 # 数据库地址
user: root # 数据库账号
password: # 数据库密码spring.datasource配置项，设置数据源的配置。这里暂时没有实际作用，仅仅是为了项目不报数据源的错误。spring.flyway配置项，设置 Flyway 的属性，而后可以被 FlywayAutoConfiguration 自动化配置。- 每个配置项的作用，胖友自己看下注释。更多的配置项，可以看看 《Spring Boot 配置属性详解 -- Migration》 文章。
- 重点看下
locations配置项，我们分别设置了 SQL 和 Java 迁移脚本的所在目录。
2.3 Application
创建 Application.java 类，配置 @SpringBootApplication 注解即可。代码如下：
// Application.java
@SpringBootApplication
public class Application {
public static void main(String[] args) {
// 启动 Spring Boot 应用
SpringApplication.run(Application.class, args);
}
}启动项目。执行日志如下：
// Flyway 的信息
2019-11-16 13:42:34.454 INFO 59115 --- [ main] o.f.c.internal.license.VersionPrinter : Flyway Community Edition 5.2.4 by Boxfuse
2019-11-16 13:42:34.619 INFO 59115 --- [ main] o.f.c.internal.database.DatabaseFactory : Database: jdbc:mysql://127.0.0.1:3306/lab-20-flyway (MySQL 8.0)
2019-11-16 13:42:34.643 WARN 59115 --- [ main] o.f.c.i.s.classpath.ClassPathScanner : Unable to resolve location classpath:db/migration
// 发现 0 个迁移脚本。
2019-11-16 13:42:34.657 INFO 59115 --- [ main] o.f.core.internal.command.DbValidate : Successfully validated 0 migrations (execution time 00:00.004s)
// 创建 flyway_schema_history 表
2019-11-16 13:42:34.671 INFO 59115 --- [ main] o.f.c.i.s.JdbcTableSchemaHistory : Creating Schema History table: `lab-20-flyway`.`flyway_schema_history`
// 打印当前数据库的迁移版本
2019-11-16 13:42:34.702 INFO 59115 --- [ main] o.f.core.internal.command.DbMigrate : Current version of schema `lab-20-flyway`: << Empty Schema >>
// 判断，没有需要迁移的脚本
2019-11-16 13:42:34.702 INFO 59115 --- [ main] o.f.core.internal.command.DbMigrate : Schema `lab-20-flyway` is up to date. No migration necessary.
// 启动项目完成
2019-11-16 13:42:34.759 INFO 59115 --- [ main] c.i.s.l.d.Application : Started Application in 1.2 seconds (JVM running for 1.596)
在启动的日志中，我们看到 Flyway 会自动创建 flyway_schema_history 表，记录 Flyway 每次迁移( migration )的历史。表结构如下：
CREATE TABLE `flyway_schema_history` (
`installed_rank` int(11) NOT NULL, -- 安装顺序，从 1 开始递增。
`version` varchar(50) COLLATE utf8mb4_bin DEFAULT NULL, -- 版本号
`description` varchar(200) COLLATE utf8mb4_bin NOT NULL, -- 迁移脚本描述
`type` varchar(20) COLLATE utf8mb4_bin NOT NULL, -- 脚本类型，目前有 SQL 和 Java 。
`script` varchar(1000) COLLATE utf8mb4_bin NOT NULL, -- 脚本地址
`checksum` int(11) DEFAULT NULL, -- 脚本校验码。避免已经执行的脚本，被人变更了。
`installed_by` varchar(100) COLLATE utf8mb4_bin NOT NULL, -- 执行脚本的数据库用户
`installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, -- 安装时间
`execution_time` int(11) NOT NULL, -- 执行时长，单位毫秒
`success` tinyint(1) NOT NULL, -- 执行结果是否成功。1-成功。0-失败
PRIMARY KEY (`installed_rank`),
KEY `flyway_schema_history_s_idx` (`success`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;2.4 SQL-based migrations
在 resources/db/migration 目录下，创建 V1.0__INIT_DB.sql SQL 迁移脚本。如下：
-- 创建用户表
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户编号',
`username` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '账号',
`password` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '密码',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
-- 插入一条数据
INSERT INTO `users`(username, password, create_time) VALUES('yudaoyuanma', 'password', now());- 比较简单，就是创建用户表
users表，并往里面插入一条记录。
重点在于 V1.0__INIT_DB.sql 的命名上。Flyway 约定如下：
FROM https://flywaydb.org/documentation/migrations#naming-1
-
Prefix 前缀：
V为版本迁移，U为回滚迁移，R为可重复迁移。在我们的示例中，我们使用
V前缀，表示版本迁移。绝大多数情况下，我们只会使用V前缀。 -
Version 版本号：每一个迁移脚本，都需要一个对应一个唯一的版本号。而脚本的执行顺序，按照版本号的顺序。一般情况下，我们使用数字自增即可。
在我们的示例中，我们使用
1.0。 -
Separator 分隔符：两个
_，即__。可配置，不过一般不配置。 -
Description 描述：描述脚本的用途。
在我们的示例中，我们使用
INIT_DB。 -
Suffix 后缀：
.sql。可配置，不过一般不配置。
我们再次启动 Application 项目。执行日志如下：
// Flyway 的信息
2019-11-16 14:20:25.893 INFO 59615 --- [ main] o.f.c.internal.license.VersionPrinter : Flyway Community Edition 5.2.4 by Boxfuse
2019-11-16 14:20:26.063 INFO 59615 --- [ main] o.f.c.internal.database.DatabaseFactory : Database: jdbc:mysql://127.0.0.1:3306/lab-20-flyway (MySQL 8.0)
// 发现一个迁移脚本，就是 V1.0__INIT_DB.sql 。
2019-11-16 14:20:26.096 INFO 59615 --- [ main] o.f.core.internal.command.DbValidate : Successfully validated 1 migration (execution time 00:00.013s)
// 打印当前数据库的迁移版本
2019-11-16 14:20:26.137 INFO 59615 --- [ main] o.f.core.internal.command.DbMigrate : Current version of schema `lab-20-flyway`: << Empty Schema >>
// 开始迁移到版本 1.0
2019-11-16 14:20:26.138 INFO 59615 --- [ main] o.f.core.internal.command.DbMigrate : Migrating schema `lab-20-flyway` to version 1.0 - INIT DB
// 可以忽略，MySQL 报的告警日志
2019-11-16 14:20:26.148 WARN 59615 --- [ main] o.f.c.i.s.DefaultSqlScriptExecutor : DB: Integer display width is deprecated and will be removed in a future release. (SQL State: HY000 - Error Code: 1681)
// 成功执行一个迁移
2019-11-16 14:20:26.157 INFO 59615 --- [ main] o.f.core.internal.command.DbMigrate : Successfully applied 1 migration to schema `lab-20-flyway` (execution time 00:00.049s)
// 启动项目完成
2019-11-16 14:20:26.214 INFO 59615 --- [ main] c.i.s.l.d.Application : Started Application in 1.236 seconds (JVM running for 1.638)
此时，我们去查询下 MySQL 。如下：
mysql> show tables;
+-------------------------+
| Tables_in_lab-20-flyway |
+-------------------------+
| flyway_schema_history |
| users |
+-------------------------+
2 rows in set (0.00 sec)
# 如上，我们可以看到两个表。
# 其中，`users` 表，就是我们需要在 `V1.0__INIT_DB.sql` 迁移脚本中，需要创建的。
mysql> SELECT * FROM users;
+----+-------------+----------+---------------------+
| id | username | password | create_time |
+----+-------------+----------+---------------------+
| 7 | yudaoyuanma | password | 2019-11-16 14:21:32 |
+----+-------------+----------+---------------------+
1 row in set (0.00 sec)
# `users` 表的该记录，就是我们希望插入的一条记录。
mysql> SELECT * FROM flyway_schema_history;
+----------------+---------+-------------+------+-------------------+-------------+--------------+---------------------+----------------+---------+
| installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
+----------------+---------+-------------+------+-------------------+-------------+--------------+---------------------+----------------+---------+
| 1 | 1.0 | INIT DB | SQL | V1.0__INIT_DB.sql | -1362702755 | root | 2019-11-16 14:21:32 | 12 | 1 |
+----------------+---------+-------------+------+-------------------+-------------+--------------+---------------------+----------------+---------+
1 row in set (0.00 sec)
# `flyway_schema_history` 表中，增加了一条版本号为 `1.0` 的，使用 `V1.0__INIT_DB.sql` 迁移脚本的日志。我们再再次启动 Application 项目。执行日志如下：
// Flyway 的信息
2019-11-16 14:30:10.925 INFO 59715 --- [ main] o.f.c.internal.license.VersionPrinter : Flyway Community Edition 5.2.4 by Boxfuse
2019-11-16 14:30:11.089 INFO 59715 --- [ main] o.f.c.internal.database.DatabaseFactory : Database: jdbc:mysql://127.0.0.1:3306/lab-20-flyway (MySQL 8.0)
// 发现一个迁移脚本，就是 V1.0__INIT_DB.sql 。
2019-11-16 14:30:11.127 INFO 59715 --- [ main] o.f.core.internal.command.DbValidate : Successfully validated 1 migration (execution time 00:00.014s)
// 打印当前数据库的迁移版本为 `1.0`
2019-11-16 14:30:11.137 INFO 59715 --- [ main] o.f.core.internal.command.DbMigrate : Current version of schema `lab-20-flyway`: 1.0
// 判断已经到达最新版本，无需执行迁移
2019-11-16 14:30:11.137 INFO 59715 --- [ main] o.f.core.internal.command.DbMigrate : Schema `lab-20-flyway` is up to date. No migration necessary.
// 启动项目完成
2019-11-16 14:30:11.196 INFO 59715 --- [ main] c.i.s.l.d.Application : Started Application in 1.141 seconds (JVM running for 1.528)
下面，我们注释掉 V1.0__INIT_DB.sql 迁移脚本中的，INSERT 操作。我们再再再次启动 Application 项目。会报如下错误：
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Validate failed: Migration checksum mismatch for migration version 1.0
-> Applied to database : -1362702755
-> Resolved locally : -883795183- Flyway 会给每个迁移脚本，计算出一个
checksum字段。这样，每次启动时，都会校验已经安装( installed )的迁移脚本，是否发生了改变。如果是，抛出异常。这样，保证不会因为脚本变更，导致出现问题。
2.5 Java-based migrations
在 cn.iocoder.springboot.lab20.databaseversioncontrol.migration 包路径下，创建 V1_1__FixUsername.java 类，修复 users 的用户名。代码如下：
// V1_1__FixUsername.java
public class V1_1__FixUsername extends BaseJavaMigration {
private Logger logger = LoggerFactory.getLogger(getClass());
@Override
public void migrate(Context context) throws Exception {
// 创建 JdbcTemplate ，方便 JDBC 操作
JdbcTemplate template = new JdbcTemplate(context.getConfiguration().getDataSource());
// 查询所有用户，如果用户名为 yudaoyuanma ，则变更成 yutou
template.query("SELECT id, username, password, create_time FROM users", new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
// 遍历返回的结果
do {
String username = rs.getString("username");
if ("yudaoyuanma".equals(username)) {
Integer id = rs.getInt("id");
template.update("UPDATE users SET username = ? WHERE id = ?",
"yutou", id);
logger.info("[migrate][更新 user({}) 的用户名({} => {})", id, username, "yutou");
}
} while (rs.next());
}
});
}
@Override
public Integer getChecksum() {
return 11; // 默认返回，是 null 。
}
@Override
public boolean canExecuteInTransaction() {
return true; // 默认返回，也是 true
}
@Override
public MigrationVersion getVersion() {
return super.getVersion(); // 默认按照约定的规则，从类名中解析获得。可以自定义
}
}- 比较简单，胖友看下代码注释。这里仅仅是示例，实际迁移的逻辑，会更加复杂。
- Java 迁移脚本，可以通过类名按照和 「2.4 SQL-based migrations」 一样的命名约定，自动获得版本号。当然，也可以通过重写
#getVersion()方法，自定义版本号。
我们再再再再次启动 Application 项目。执行日志如下：
// Flyway 的信息
2019-11-16 14:45:30.733 INFO 59941 --- [ main] o.f.c.internal.license.VersionPrinter : Flyway Community Edition 5.2.4 by Boxfuse
2019-11-16 14:45:30.907 INFO 59941 --- [ main] o.f.c.internal.database.DatabaseFactory : Database: jdbc:mysql://127.0.0.1:3306/lab-20-flyway (MySQL 8.0)
// 发现一个迁移脚本，就是 V1.0__INIT_DB.sql 和 V1_1__FixUsername.java
2019-11-16 14:45:30.946 INFO 59941 --- [ main] o.f.core.internal.command.DbValidate : Successfully validated 2 migrations (execution time 00:00.014s)
// 打印当前数据库的迁移版本为 `1.0`
2019-11-16 14:45:30.956 INFO 59941 --- [ main] o.f.core.internal.command.DbMigrate : Current version of schema `lab-20-flyway`: 1.0
// 开始迁移到版本 1.1
2019-11-16 14:45:30.957 INFO 59941 --- [ main] o.f.core.internal.command.DbMigrate : Migrating schema `lab-20-flyway` to version 1.1 - FixUsername
2019-11-16 14:45:30.977 INFO 59941 --- [ main] c.i.s.l.d.migration.V1_1__FixUsername : [migrate][更新 user(7) 的用户名(yudaoyuanma => yutou)
// 成功执行一个迁移
2019-11-16 14:45:30.985 INFO 59941 --- [ main] o.f.core.internal.command.DbMigrate : Successfully applied 1 migration to schema `lab-20-flyway` (execution time 00:00.034s)
// 启动项目完成
2019-11-16 14:45:31.039 INFO 59941 --- [ main] c.i.s.l.d.Application : Started Application in 1.221 seconds (JVM running for 1.61)
此时，我们去查询下 MySQL 。如下：
mysql> SELECT * FROM users;
+----+-------------+----------+---------------------+
| id | username | password | create_time |
+----+-------------+----------+---------------------+
| 7 | yutou | password | 2019-11-16 14:21:32 |
+----+-------------+----------+---------------------+
1 row in set (0.00 sec)
# `users` 表的该记录，用户名被修改为 yutou 。
mysql> SELECT * FROM flyway_schema_history;
+----------------+---------+-------------+------+--------------------------------------------------------------------------------+-------------+--------------+---------------------+----------------+---------+
| installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
+----------------+---------+-------------+------+--------------------------------------------------------------------------------+-------------+--------------+---------------------+----------------+---------+
| 1 | 1.0 | INIT DB | SQL | V1.0__INIT_DB.sql | -1362702755 | root | 2019-11-16 14:21:32 | 12 | 1 |
| 2 | 1.1 | FixUsername | JDBC | cn.iocoder.springboot.lab20.databaseversioncontrol.migration.V1_1__FixUsername | 11 | root | 2019-11-16 14:45:30 | 19 | 1 |
+----------------+---------+-------------+------+--------------------------------------------------------------------------------+-------------+--------------+---------------------+----------------+---------+
2 rows in set (0.00 sec)
# `flyway_schema_history` 表中，增加了一条版本号为 `1.1` 的，使用 `V1_1__FixUsername.sql` 迁移脚本的日志。2.6 其它功能
Flyway 支持 SQL Callbacks 和 Java Callbacks 两种回调方式，让我们在 Flyway 的执行过程中，可以实现自定义的拓展。
在上述的示例，我们是基于 Spring Boot 的使用方式。而 Flyway 还提供了如下方式：
- API (Java / Android) 直接使用 Java 原生的 API 。
- Command-line tool 命令行工具
- Maven 插件
- Gralde 插件
- Community Plugins and Integrations ，社区提供了 Ant、Intellij IDEA、Jenkins 等插件。
Flyway 还有一些其它细节，建议抽时间，通读下 Documentation 文档。
3. Liquibase
示例代码对应仓库：lab-20-database-version-control-liquibase 。
在 Liquibase 的官网 https://www.liquibase.org/ 中，对自己的介绍是：
Liquibase is the leading open source tool for database change and deployment management.
Liquibase 是用于数据库变更和部署管理的领先的开源工具。
Liquibase 支持的数据库，主要是关系数据库。如下图表格：
| Database | Type Name | Notes |
|---|---|---|
| MySQL | mysql | No Issues |
| MariaDB | mysql | MariaDB is 100% compatible with MySQL per MariaDB developers |
| PostgreSQL | postgresql | 8.2+ is required to use the "drop all database objects" functionality. |
| Oracle | oracle | 11g driver is required when using the diff tool on databases running with AL32UTF8 or AL16UTF16 |
| SQL Server | mssql | No Issues |
| Sybase_Enterprise | sybase | ASE 12.0+ required. "select into" database option needs to be set. Best driver is JTDS. Sybase does not support transactions for DDL so rollbacks will not work on failures. Foreign keys can not be dropped which can break the rollback or dropAll functionality. |
| Sybase_Anywhere | asany | Since 1.9 |
| DB2 | db2 | No Issues. Will auto-call REORG when necessary. |
| Apache_Derby | derby | No Issues |
| HSQL | hsqldb | No Issues |
| H2 | h2 | No Issues |
| Informix | informix | No Issues |
| Firebird | firebird | No Issues |
| SQLite | sqlite | No Issues |
Liquibase 通过在变更日志( Change Log )文件，配置每一个变更集( Change Set )，实现数据库变更的管理。
Liquibase 提供了多种格式，如下：
- XML Format
- YAML Format
- JSON Format
- SQL Format
- Other Formats
在 Spring Boot 中，默认配置使用 YAML Format 。所以我们在入门的示例中，也使用这种格式。
Liquibase 在变更集( Change Set )中，除了提供了和 Flyway 的 SQL-based migrations 和 Java-based migrations 方式之外，额外提供了基于配置，自动生成对应的 SQL 操作。我们姑且称它为 “Property-based migrations” 吧。
下面，就让我们开始入门 Liquibase 吧。
3.1 引入依赖
在 pom.xml 文件中，引入相关依赖。
org.springframework.boot
spring-boot-starter-parent
2.1.3.RELEASE
4.0.0
lab-20-database-version-control-liquibase
org.springframework.boot
spring-boot-starter-jdbc
mysql
mysql-connector-java
org.liquibase
liquibase-core
具体每个依赖的作用，胖友自己认真看下艿艿添加的所有注释噢。
3.2 应用配置文件
在 resources 目录下，创建 application.yaml 配置文件。配置如下：
spring:
# datasource 数据源配置内容，对应 DataSourceProperties 配置属性类
datasource:
url: jdbc:mysql://127.0.0.1:3306/lab-20-liquibase?useSSL=false&useUnicode=true&characterEncoding=UTF-8
driver-class-name: com.mysql.jdbc.Driver
username: root # 数据库账号
password: # 数据库密码
# Liquibase 配置内容，对应 LiquibaseProperties 配置项
liquibase:
enabled: true # 开启 Liquibase 功能。默认为 true 。
change-log: classpath:/db/changelog/db.changelog-master.yaml # Liquibase 配置文件地址
url: jdbc:mysql://127.0.0.1:3306/lab-20-liquibase?useSSL=false&useUnicode=true&characterEncoding=UTF-8 # 数据库地址
user: root # 数据库账号
password: # 数据库密码spring.datasource配置项，设置数据源的配置。这里暂时没有实际作用，仅仅是为了项目不报数据源的错误。spring.liquibase配置项，设置 Liquibase 的属性，而后可以被 LiquibaseAutoConfiguration 自动化配置。- 每个配置项的作用，胖友自己看下注释。更多的配置项，可以看看 《Spring Boot 配置属性详解 -- Migration》 文章。
- 重点看下
change-log配置项，我们设置了变更日志( Change Log )文件的路径为"classpath:/db/changelog/db.changelog-master.yaml"。
3.3 变更文件 Change Log
在 resources/db/changelog 目录下，创建 db.changelog-master.yaml 变更文件。如下：
databaseChangeLog:
- changeSet: # 对应一个 ChangeSet 对象
id: 0 # ChangeSet 编号
author: yunai # 作者
comments: 空 # 备注- 在
databaseChangeLog配置下，我们可以配置多个changeSet配置项。每个changeSet配置项，代表一个 变更集( Change Set )。 - 这里，我们先配置一个“空”的
changeSet配置项，方便我们稍后启动项。 真正的changeSet配置项，我们会按照 Property-based migrations、SQL-based migrations、Java-based migrations 示例顺序，详细解释。
3.4 Application
创建 Application.java 类，配置 @SpringBootApplication 注解即可。代码如下：
// Application.java
@SpringBootApplication
public class Application {
public static void main(String[] args) {
// 启动 Spring Boot 应用
SpringApplication.run(Application.class, args);
}
}启动项目。执行日志如下：
// 获得 DATABASECHANGELOGLOCK 数量。此时，该 DATABASECHANGELOGLOCK 表是不存在的。
2019-11-16 19:37:01.679 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
// 因为 DATABASECHANGELOGLOCK 表不存在，所以进行创建
2019-11-16 19:37:01.697 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : CREATE TABLE `lab-20-liquibase`.DATABASECHANGELOGLOCK (ID INT NOT NULL, `LOCKED` BIT(1) NOT NULL, LOCKGRANTED datetime NULL, LOCKEDBY VARCHAR(255) NULL, CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID))
// 重新获得 DATABASECHANGELOGLOCK 数量。
2019-11-16 19:37:01.704 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
// 删除 DATABASECHANGELOGLOCK 所有记录。为什么这么做，暂时不造，没去细研究。猜测，避免其他 JVM 进程，异常崩溃，未释放锁
2019-11-16 19:37:01.709 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : DELETE FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
// 插入 DATABASECHANGELOGLOCK 记录，id = 1
2019-11-16 19:37:01.709 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.DATABASECHANGELOGLOCK (ID, `LOCKED`) VALUES (1, 0)
// 查询 DATABASECHANGELOGLOCK 记录，id = 1
2019-11-16 19:37:01.711 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT `LOCKED` FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK WHERE ID=1
// 成功获得到 DATABASECHANGELOGLOCK 锁
2019-11-16 19:37:01.716 INFO 65543 --- [ main] l.lockservice.StandardLockService : Successfully acquired change log lock
// 创建 DATABASECHANGELOG 表
2019-11-16 19:37:02.485 INFO 65543 --- [ main] l.c.StandardChangeLogHistoryService : Creating database history table with name: `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 19:37:02.486 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : CREATE TABLE `lab-20-liquibase`.DATABASECHANGELOG (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED datetime NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35) NULL, `DESCRIPTION` VARCHAR(255) NULL, COMMENTS VARCHAR(255) NULL, TAG VARCHAR(255) NULL, LIQUIBASE VARCHAR(20) NULL, CONTEXTS VARCHAR(255) NULL, LABELS VARCHAR(255) NULL, DEPLOYMENT_ID VARCHAR(10) NULL)
// 获得 DATABASECHANGELOG 数量。
2019-11-16 19:37:02.494 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 19:37:02.496 INFO 65543 --- [ main] l.c.StandardChangeLogHistoryService : Reading from `lab-20-liquibase`.DATABASECHANGELOG
// 获得 DATABASECHANGELOG 所有记录。
2019-11-16 19:37:02.496 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT * FROM `lab-20-liquibase`.DATABASECHANGELOG ORDER BY DATEEXECUTED ASC, ORDEREXECUTED ASC
// 获得 DATABASECHANGELOGLOCK 数量。
2019-11-16 19:37:02.497 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
// 读取 Change Log 文件的 Change Set 配置
2019-11-16 19:37:02.500 INFO 65543 --- [ main] liquibase.changelog.ChangeSet : ChangeSet classpath:/db/changelog/db.changelog-master.yaml::0::yunai ran successfully in 1ms
// 插入 DATABASECHANGELOG 记录，对应 Change Set id = 0 的迁移，执行成功
2019-11-16 19:37:02.501 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT MAX(ORDEREXECUTED) FROM `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 19:37:02.503 INFO 65543 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, `DESCRIPTION`, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('0', 'yunai', 'classpath:/db/changelog/db.changelog-master.yaml', NOW(), 1, '8:d41d8cd98f00b204e9800998ecf8427e', 'empty', '', 'EXECUTED', NULL, NULL, '3.6.3', '3645022498')
// 释放锁
2019-11-16 19:37:02.506 INFO 65543 --- [ main] l.lockservice.StandardLockService : Successfully released change log lock
// 应用启动成功
2019-11-16 19:37:02.582 INFO 65543 --- [ main] c.i.s.l.d.Application : Started Application in 2.242 seconds (JVM running for 2.675)- 在整个日志中，我可以看到
ID = 0的变更集合( Change Set )完成了执行。
在启动的日志中，我们看到 Liquibase 会自动创建两张表：
-
DATABASECHANGELOG表，数据库变更日志。每一条记录，对应记录每个变更集合( Change Set ) 的执行日志。表结构如下：
CREATE TABLE `DATABASECHANGELOG` (
`ID` varchar(255) COLLATE utf8mb4_bin NOT NULL, -- Change Set 编号
`AUTHOR` varchar(255) COLLATE utf8mb4_bin NOT NULL, -- 作者
`FILENAME` varchar(255) COLLATE utf8mb4_bin NOT NULL, -- Change Log 文件路径
`DATEEXECUTED` datetime NOT NULL, -- 执行时间
`ORDEREXECUTED` int(11) NOT NULL, -- 执行的顺序
`EXECTYPE` varchar(10) COLLATE utf8mb4_bin NOT NULL, -- 执行类型。枚举值有 EXECUTED/FAILED/SKIPPED/RERAN/MARK_RAN
`MD5SUM` varchar(35) COLLATE utf8mb4_bin DEFAULT NULL, -- MD5 校验码
`DESCRIPTION` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- 描述
`COMMENTS` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- 备注
`TAG` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- Tag 标签
`LIQUIBASE` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL, -- LIQUIBASE 版本号
`CONTEXTS` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- 上下文
`LABELS` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- Label 标签
`DEPLOYMENT_ID` varchar(10) COLLATE utf8mb4_bin DEFAULT NULL -- 部署编号
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;DATABASECHANGELOGLOCK表，DATABASECHANGELOG表的锁，用于确保多个 JVM 进程，同时 Liquibase 尝试变更数据库。表结构如下：
CREATE TABLE `DATABASECHANGELOGLOCK` (
`ID` int(11) NOT NULL, -- 锁的编号。
`LOCKED` bit(1) NOT NULL, -- 是否锁。1-锁，0-未锁
`LOCKGRANTED` datetime DEFAULT NULL, -- 获得锁的时间
`LOCKEDBY` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL, -- 锁定人
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;-
- 目前，只有一条记录。也就是说，有且仅有一个 JVM 进程获得 DATABASECHANGELOG 表的锁成功。
此时，我们去查询下 MySQL 。如下：
mysql> SELECT * FROM DATABASECHANGELOG;
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-------------+----------+------+-----------+----------+--------+---------------+
| ID | AUTHOR | FILENAME | DATEEXECUTED | ORDEREXECUTED | EXECTYPE | MD5SUM | DESCRIPTION | COMMENTS | TAG | LIQUIBASE | CONTEXTS | LABELS | DEPLOYMENT_ID |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-------------+----------+------+-----------+----------+--------+---------------+
| 0 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 19:37:02 | 1 | EXECUTED | 8:d41d8cd98f00b204e9800998ecf8427e | empty | | NULL | 3.6.3 | NULL | NULL | 3645022498 |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-------------+----------+------+-----------+----------+--------+---------------+
1 row in set (0.00 sec)
# 查看到一条 `ID = 0` 的 `DATABASECHANGELOG` 记录，表示变更集合( Change Set ) `ID = 0` 完成了执行。
mysql> SELECT * FROM DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
| 1 | 0 | NULL | NULL |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
# 查看到一条处于释放状态的锁记录。再次启动项目。执行日志如下：
// 获得 DATABASECHANGELOGLOCK 数量。
2019-11-16 20:22:24.589 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
2019-11-16 20:22:24.594 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK
// 查询 DATABASECHANGELOGLOCK 记录，id = 1
2019-11-16 20:22:24.595 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT `LOCKED` FROM `lab-20-liquibase`.DATABASECHANGELOGLOCK WHERE ID=1
// 成功获得到 DATABASECHANGELOGLOCK 锁
2019-11-16 20:22:24.603 INFO 66473 --- [ main] l.lockservice.StandardLockService : Successfully acquired change log lock
// 获得一条 DATABASECHANGELOG 。过滤 MD5SUM 非空且一条记录，有点奇怪，后面在细细研究。
2019-11-16 20:22:25.378 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT MD5SUM FROM `lab-20-liquibase`.DATABASECHANGELOG WHERE MD5SUM IS NOT NULL LIMIT 1
// 获得 DATABASECHANGELOG 数量。
2019-11-16 20:22:25.379 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT COUNT(*) FROM `lab-20-liquibase`.DATABASECHANGELOG
// 获得 DATABASECHANGELOG 所有记录。
2019-11-16 20:22:25.380 INFO 66473 --- [ main] l.c.StandardChangeLogHistoryService : Reading from `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 20:22:25.380 INFO 66473 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT * FROM `lab-20-liquibase`.DATABASECHANGELOG ORDER BY DATEEXECUTED ASC, ORDEREXECUTED ASC
// 释放锁
2019-11-16 20:22:25.385 INFO 66473 --- [ main] l.lockservice.StandardLockService : Successfully released change log lock
2019-11-16 20:22:25.447 INFO 66473 --- [ main] c.i.s.l.d.Application : Started Application in 2.215 seconds (JVM running for 2.62)
- 在整个日志中，我可以看到
ID = 0的变更集合( Change Set )不会重复执行。
下面，我们修改 ID = 0 的变更集合( Change Set )，如下：
databaseChangeLog:
- changeSet: # 对应一个 ChangeSet 对象
id: 0 # ChangeSet 编号
author: yunai # 作者
comments: 空 # 备注
changes:
- createTable: # 创建表，对应 CreateTableChange 对象。
tableName: users # 表名
remarkds: 用户表 # 表注释
columns: # 对应 ColumnConfig 数组
- column:
name: id # 字段名
type: int # 字段类型
autoIncrement: true # 自增
constraints: # 限制条件，对应一个 ConstraintsConfig 对象
primaryKey: true # 主键
nullable: false # 不允许空
-
增加了
changes配置项。 -
我们再再再次启动项目。会报如下错误：
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
1 change sets check sum
classpath:/db/changelog/db.changelog-master.yaml::0::yunai was: 8:d41d8cd98f00b204e9800998ecf8427e but is now: 8:2fb4d9484c5982a97eb8d580ba934395
- 我们会发现，Liquibase 会给每个变更集合( Change Set )，计算出一个
MD5SUM字段。这样，每次启动时，都会校验已经执行的变更集合( Change Set )，是否发生了改变。如果是，抛出异常。这样，保证不会因为 变更集合( Change Set ) 变更，导致出现问题。 -
测试完成，我们还是将
ID = 0的变更集合( Change Set ) 恢复原样。
3.5 Property-based migrations
修改 db.changelog-master.yaml 变更日志，增加 ID = 1 的变更集合( Change Set ) 。代码如下：
- changeSet: # 对应一个 ChangeSet 对象
id: 1 # ChangeSet 编号
author: yunai # 作者
comments: 初始化 users 表 # 备注
changes: # 对应 Change 数组。Change 是一个接口，每种操作对应一种 Change 实现类
- createTable: # 创建表，对应 CreateTableChange 对象。
tableName: users # 表名
remarkds: 用户表 # 表注释
columns: # 对应 ColumnConfig 数组
- column:
name: id # 字段名
type: int # 字段类型
autoIncrement: true # 自增
constraints: # 限制条件，对应一个 ConstraintsConfig 对象
primaryKey: true # 主键
nullable: false # 不允许空
- column:
name: username
type: varchar(64)
constraints:
nullable: false
- column:
name: password
type: varchar(32)
constraints:
nullable: false
- column:
name: create_time
type: datetime
constraints:
nullable: false
- insert: # 插入记录，对应 InsertDataChange 对象。
tableName: users # 表名
columns: # 对应 ColumnConfig 数组
- column:
name: username # 字段名
value: yudaoyuanma # 值
- column:
name: password
value: password
- column:
name: create_time
value: now()- 在这个变更集合( Change Set )中，我们添加了两个变更( Change )，分别用于创建
users表、插入一条users记录。 - Liquibase 基于上述的配置，自动生成对应的 SQL 操作。
启动项目。执行日志如下：
// ... 省略雷同日志
// 创建 `users` 表
2019-11-16 21:21:42.317 INFO 67111 --- [ main] liquibase.executor.jvm.JdbcExecutor : CREATE TABLE `lab-20-liquibase`.users (id INT AUTO_INCREMENT NOT NULL, username VARCHAR(64) NOT NULL, password VARCHAR(32) NOT NULL, create_time datetime NOT NULL, CONSTRAINT PK_USERS PRIMARY KEY (id))
2019-11-16 21:21:42.323 INFO 67111 --- [ main] liquibase.changelog.ChangeSet : Table users created
// 插入一条 `users` 表的记录
2019-11-16 21:21:42.323 INFO 67111 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.users (username, password, create_time) VALUES ('yudaoyuanma', 'password', now())
2019-11-16 21:21:42.324 INFO 67111 --- [ main] liquibase.changelog.ChangeSet : New row inserted into users
// 输出 Change Log 文件的 Change Set 全部执行成功
2019-11-16 21:21:42.325 INFO 67111 --- [ main] liquibase.changelog.ChangeSet : ChangeSet classpath:/db/changelog/db.changelog-master.yaml::1::yunai ran successfully in 10ms
// 插入 DATABASECHANGELOG 记录，对应 Change Set id = 1 的迁移，执行成功
2019-11-16 21:21:42.326 INFO 67111 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT MAX(ORDEREXECUTED) FROM `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 21:21:42.327 INFO 67111 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, `DESCRIPTION`, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1', 'yunai', 'classpath:/db/changelog/db.changelog-master.yaml', NOW(), 3, '8:1dcffd4c4f87b02e3758bf6b4ecea471', 'createTable tableName=users; insert tableName=users', '', 'EXECUTED', NULL, NULL, '3.6.3', '3651302309')
// ... 省略雷同日志- 在整个日志中，我可以看到 ID = 1 的变更集合( Change Set )完成了执行。在这个过程中，我们可以看到两条分别用于创建
users表和插入users记录的 SQL 。
此时，我们去查询下 MySQL 。如下：
mysql> SELECT * FROM DATABASECHANGELOG;
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| ID | AUTHOR | FILENAME | DATEEXECUTED | ORDEREXECUTED | EXECTYPE | MD5SUM | DESCRIPTION | COMMENTS | TAG | LIQUIBASE | CONTEXTS | LABELS | DEPLOYMENT_ID |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| 0 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 1 | EXECUTED | 8:d41d8cd98f00b204e9800998ecf8427e | empty | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
| 1 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 2 | EXECUTED | 8:1dcffd4c4f87b02e3758bf6b4ecea471 | createTable tableName=users; insert tableName=users | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
2 rows in set (0.00 sec)
# 多查看到一条 `ID = 1` 的 `DATABASECHANGELOG` 记录，表示变更集合( Change Set ) `ID = 1` 完成了执行。并且，在描述中，我们可以看到对该更集合( Change Set )的简单说明。
mysql> SELECT * FROM DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
| 1 | 0 | NULL | NULL |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
# 查看到一条处于释放状态的锁记录。使用 Property-based migrations 方式，我们无需编写相应的 SQL 。虽然在编写上有些啰嗦，但是易读性还是不错的。
3.6 SQL-based migrations
修改 db.changelog-master.yaml 变更日志，增加 ID = 2 的变更集合( Change Set ) 。代码如下：
- changeSet: # 对应一个 ChangeSet 对象
id: 2 # ChangeSet 编号
author: yunai # 作者
comments: 初始化 users2 表 # 备注
changes: # 对应 Change 数组。Change 是一个接口，每种操作对应一种 Change 实现类
- sqlFile: # 使用 SQL 文件，对应 SQLFileChange 对象
encoding: utf8
path: classpath:db/changelog/sqlfile/CHAGE_SET_2_INIT_DB.sql- 这个示例，我们实现的是和 「3.5 Property-based migrations」 一样的效果，只是操作的是
users2表。 - 对应文档为 《Liquibase 文档 —— SQL FILE》 。
- 通过在
sqlFile配置项的path属性，设置使用自定义 SQL 文件的路径。
在 resources/db/changelog/sqlfile 目录下，创建 CHAGE_SET_2_INIT_DB.sql 变更文件。如下：
-- 创建用户表
CREATE TABLE `users2` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户编号',
`username` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '账号',
`password` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '密码',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
-- 插入一条数据
INSERT INTO `users2`(username, password, create_time) VALUES('yudaoyuanma', 'password', now());
- 这里的 SQL ，和我们在 「2.4 SQL-based migrations」 是一样的。
启动项目。执行日志如下：
// ... 省略雷同日志
// 执行 CHAGE_SET_2_INIT_DB.sql 里的 SQL
2019-11-16 21:40:05.793 INFO 67368 --- [ main] liquibase.executor.jvm.JdbcExecutor : -- 创建用户表
CREATE TABLE `users2` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户编号',
`username` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '账号',
`password` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '密码',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
2019-11-16 21:40:05.800 INFO 67368 --- [ main] liquibase.executor.jvm.JdbcExecutor : -- 插入一条数据
INSERT INTO `users2`(username, password, create_time) VALUES('yudaoyuanma', 'password', now())
2019-11-16 21:40:05.801 INFO 67368 --- [ main] liquibase.changelog.ChangeSet : SQL in file classpath:db/changelog/sqlfile/CHAGE_SET_2_INIT_DB.sql executed
// 输出 Change Log 文件的 Change Set 全部执行成功
2019-11-16 21:40:05.802 INFO 67368 --- [ main] liquibase.changelog.ChangeSet : ChangeSet classpath:/db/changelog/db.changelog-master.yaml::2::yunai ran successfully in 13ms
// 插入 DATABASECHANGELOG 记录，对应 Change Set id = 2 的迁移，执行成功
2019-11-16 21:40:05.802 INFO 67368 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT MAX(ORDEREXECUTED) FROM `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 21:40:05.804 INFO 67368 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, `DESCRIPTION`, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2', 'yunai', 'classpath:/db/changelog/db.changelog-master.yaml', NOW(), 3, '8:c224782d41ad7fac92699ebf392c7f5e', 'sqlFile', '', 'EXECUTED', NULL, NULL, '3.6.3', '3652405782')
// ... 省略雷同日志- 在整个日志中，我可以看到 ID = 1 的变更集合( Change Set )完成了执行。在这个过程中，我们可以看到
CHAGE_SET_2_INIT_DB.sql的 SQL 被执行。
此时，我们去查询下 MySQL 。如下：
mysql> SELECT * FROM DATABASECHANGELOG;
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| ID | AUTHOR | FILENAME | DATEEXECUTED | ORDEREXECUTED | EXECTYPE | MD5SUM | DESCRIPTION | COMMENTS | TAG | LIQUIBASE | CONTEXTS | LABELS | DEPLOYMENT_ID |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| 0 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 1 | EXECUTED | 8:d41d8cd98f00b204e9800998ecf8427e | empty | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
| 1 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 2 | EXECUTED | 8:1dcffd4c4f87b02e3758bf6b4ecea471 | createTable tableName=users; insert tableName=users | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
| 2 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:40:05 | 3 | EXECUTED | 8:c224782d41ad7fac92699ebf392c7f5e | sqlFile | | NULL | 3.6.3 | NULL | NULL | 3652405782 |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
3 rows in set (0.00 sec)
# 多查看到一条 `ID = 2` 的 `DATABASECHANGELOG` 记录，表示变更集合( Change Set ) `ID = 2` 完成了执行。并且，在描述中，我们可以看到 `sqlFile` 。
mysql> SELECT * FROM DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
| 1 | 0 | NULL | NULL |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
# 查看到一条处于释放状态的锁记录。相比 Property-based migrations 方式来说，艿艿更愿意使用 SQL-based migrations 。毕竟，我们更加熟悉 SQL 语法，交给 DBA 审计也更加方便。
3.7 Java-based migrations
在 cn.iocoder.springboot.lab20.databaseversioncontrol.migration 包路径下，创建 CHANGE_SET_3_FixUsername.java 类，修复 users 的用户名。代码如下：
// CHANGE_SET_3_FixUsername.java
public class CHANGE_SET_3_FixUsername implements CustomTaskChange {
private Logger logger = LoggerFactory.getLogger(getClass());
@Override
public void execute(Database database) throws CustomChangeException {
JdbcConnection connection = (JdbcConnection) database.getConnection();
try (PreparedStatement psmt = connection.prepareStatement("SELECT id, username, password, create_time FROM users")) {
try (ResultSet rs = psmt.executeQuery()) {
while (rs.next()) {
String username = rs.getString("username");
if ("yudaoyuanma".equals(username)) {
Integer id = rs.getInt("id");
// 这里，再来一刀更新操作，偷懒不写了。
logger.info("[migrate][更新 user({}) 的用户名({} => {})", id, username, "yutou");
}
}
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
@Override
public String getConfirmationMessage() {
return null;
}
@Override
public void setUp() throws SetupException {
}
@Override
public void setFileOpener(ResourceAccessor resourceAccessor) {
}
@Override
public ValidationErrors validate(Database database) {
return null;
}
}- 通过实现 CustomTaskChange 接口，实现 Java 自定义迁移逻辑。
- 这里有一点比较蛋疼，在
#execute(Database database)方法中，提供给我们的是 Database 对象，无法方便的获得 DataSource 对象，从而使用 Spring JdbcTemplate 。
修改 db.changelog-master.yaml 变更日志，增加 ID = 3 的变更集合( Change Set ) 。代码如下：
- changeSet: # 对应一个 ChangeSet 对象
id: 3 # ChangeSet 编号
author: yunai # 作者
comments: 修复 `users` 的用户名 # 备注
changes: # 对应 Change 数组。Change 是一个接口，每种操作对应一种 Change 实现类
- customChange: {class: cn.iocoder.springboot.lab20.databaseversioncontrol.migration.CHANGE_SET_3_FixUsername} # 对应 CustomTaskChange
- 对应文档为 《Liquibase 文档 —— Custom Change》 。
- 通过在
customChange配置项的class属性，设置使用自定义 CustomTaskChange 的实现的类名。
启动项目。执行日志如下：
// ... 省略雷同日志
// CHANGE_SET_3_FixUsername 的执行日志
2019-11-16 21:56:48.782 INFO 67585 --- [ main] c.i.s.l.d.m.CHANGE_SET_3_FixUsername : [migrate][更新 user(1) 的用户名(yudaoyuanma => yutou)
2019-11-16 21:56:48.782 INFO 67585 --- [ main] liquibase.changelog.ChangeSet : null
// 插入 DATABASECHANGELOG 记录，对应 Change Set id = 3 的迁移，执行成功
2019-11-16 21:56:48.783 INFO 67585 --- [ main] liquibase.changelog.ChangeSet : ChangeSet classpath:/db/changelog/db.changelog-master.yaml::3::yunai ran successfully in 3ms
2019-11-16 21:56:48.783 INFO 67585 --- [ main] liquibase.executor.jvm.JdbcExecutor : SELECT MAX(ORDEREXECUTED) FROM `lab-20-liquibase`.DATABASECHANGELOG
2019-11-16 21:56:48.784 INFO 67585 --- [ main] liquibase.executor.jvm.JdbcExecutor : INSERT INTO `lab-20-liquibase`.DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, `DESCRIPTION`, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('3', 'yunai', 'classpath:/db/changelog/db.changelog-master.yaml', NOW(), 4, '8:2595b6826984b91149063782c4cd6c29', 'customChange', '', 'EXECUTED', NULL, NULL, '3.6.3', '3653408775')
// ... 省略雷同日志- 在整个日志中，我可以看到 ID = 3 的变更集合( Change Set )完成了执行。在这个过程中，我们可以看不到 CHANGE_SET_3_FixUsername 的任何信息，除了我们打的 INFO 日志。所以，在使用 Java-based migrations 方式时，最好自己打下日志，方便排查。
此时，我们去查询下 MySQL 。如下：
mysql> SELECT * FROM DATABASECHANGELOG;
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| ID | AUTHOR | FILENAME | DATEEXECUTED | ORDEREXECUTED | EXECTYPE | MD5SUM | DESCRIPTION | COMMENTS | TAG | LIQUIBASE | CONTEXTS | LABELS | DEPLOYMENT_ID |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
| 0 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 1 | EXECUTED | 8:d41d8cd98f00b204e9800998ecf8427e | empty | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
| 1 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:35:09 | 2 | EXECUTED | 8:1dcffd4c4f87b02e3758bf6b4ecea471 | createTable tableName=users; insert tableName=users | | NULL | 3.6.3 | NULL | NULL | 3652109350 |
| 2 | yunai | classpath:/db/changelog/db.changelog-master.yaml | 2019-11-16 21:40:05 | 3 | EXECUTED | 8:c224782d41ad7fac92699ebf392c7f5e | sqlFile | | NULL | 3.6.3 | NULL | NULL | 3652405782 |
+----+--------+--------------------------------------------------+---------------------+---------------+----------+------------------------------------+-----------------------------------------------------+----------+------+-----------+----------+--------+---------------+
3 rows in set (0.00 sec)
# 多查看到一条 `ID = 2` 的 `DATABASECHANGELOG` 记录，表示变更集合( Change Set ) `ID = 2` 完成了执行。并且，在描述中，我们可以看到 `sqlFile` 。
mysql> SELECT * FROM DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
| 1 | 0 | NULL | NULL |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
# 查看到一条处于释放状态的锁记录。3.8 其它功能
在上述的示例，我们是基于 Spring Boot 的使用方式。而 Flyway 还提供了如下方式：
- Java API 直接使用 Java 原生的 API 。
- Command Line 命令行工具
- Ant 任务
- Maven 插件
- Gralde 插件
- ... 等等
Liquibase 还有一些其它细节，建议抽时间，通读下 Documentation 文档。
在写这篇文章的过程中，艿艿也在网上搜索 Flyway 和 Liquibase 的对比。毕竟，咱仅仅是做了这两者的入门，实际使用的情况，是否有什么最佳实践，又或者有什么坑，需要有在项目中真正在实践的人的经验分享。目前暂时只找到 《数据库迁移工具 Flyway 对比 Liquibase》 一文，作者的观点是：
两款数据库迁移工具其实定位上是差别的，一般我的倾向是小项目，整体变动不大的用 Flyway ，而大应用和企业应用用 Liquibase 更合适。
- 不过从入门看下来，Liquibase 并未看到比 Flyway 带来多大的优势，反倒 Flyway 基于“约定大于配置”的思想，使用上更加便捷。欢迎胖友能够解答下艿艿在这块的疑惑。
关于最佳实践，目前找到比较合适的两篇，如下：
- 《Spring Boot 使用 Liquibase 最佳实》
- 《Spring Boot 系列: 使用 flyway 管理数据库版本》 文末的 flyway 最佳实践的部分。
在实际项目使用时，可能还需要额外考虑一些事情，例如说：
- 大表直接添加索引，直接导致线上故障。
- 内部有 DBA ，数据库调整需要内部审核。
另外，项目发版时，涉及到的数据变更，不仅仅有关系数据库，可能还有 MongoDB、Redis、Elasticsearch 等等数据源的变更。特别是，可能涉及到数据修复，需要编写 Java 代码的情况。和朋友沟通了下，目前采用如下三种方法：
思路都是一致的，只是形态不同。
- 1、创建迁移 Migration 项目，专门编写数据相关变更的脚本。然后连接各种环境，本机手动运行。
- 2、在定时任务项目中，创建迁移 Migration Job 类，编写数据变更的脚本。然后，部署到服务器上，通过调度中心触发运行。
- 3、在业务项目中，创建迁移 API 接口，编写数据变更的脚本。然后，部署到服务器上，通过调用该 API 接口运行。