4. Flyway入门:工作原理、安装配置与命令行操作
Flyway 是目前最流行的开源数据库迁移工具之一,采用“约定优于配置”的设计哲学,通过版本化的 SQL 脚本实现对数据库 schema 的增量变更管理。本节将系统讲解 Flyway 的核心工作原理、安装配置方法以及最常用的四个命令行操作:migrate、info、validate 和 baseline。
4.1 Flyway 工作原理
Flyway 的核心机制是在目标数据库中维护一张元数据表(默认名为 flyway_schema_history),用于记录所有已执行的迁移脚本及其校验和。每次执行迁移时,Flyway 会扫描指定路径下的迁移脚本,与元数据表中的记录进行比对,只执行尚未运行过的脚本,并保证每个脚本只执行一次且顺序严格递增。
4.2 Flyway 的安装与配置
4.2.1 安装方式
Flyway 提供多种安装方式,适用于不同开发环境。以下为三种主流安装方式:
| 安装方式 | 适用场景 | 命令/步骤 |
|---|---|---|
| 命令行(CLI) | 本地开发、CI/CD 节点 | 下载 tar.gz/zip 包,解压后配置 PATH |
| Maven 插件 | Java 项目构建集成 | 在 pom.xml 中添加 flyway-maven-plugin |
| Gradle 插件 | Gradle 项目构建集成 | 在 build.gradle 中应用 org.flywaydb.flyway 插件 |
| Docker 镜像 | 容器化 CI/CD 流水线 | docker pull flyway/flyway |
4.2.2 配置文件(flyway.conf)
Flyway 通过 flyway.conf 文件集中管理数据库连接与行为参数。以下为典型配置示例:
# flyway.conf
flyway.url=jdbc:postgresql://localhost:5432/mydb
flyway.user=db_user
flyway.password=db_password
flyway.locations=filesystem:./sql/migrations
flyway.schemas=public
flyway.baselineOnMigrate=true
flyway.encoding=UTF-8
flyway.placeholderReplacement=true
flyway.placeholders.env=dev
配置要点:
flyway.locations:指定迁移脚本存放路径,支持filesystem:和classpath:前缀。flyway.baselineOnMigrate:当数据库已有表结构但无元数据表时,自动执行 baseline 操作。flyway.placeholders:支持在 SQL 脚本中使用${placeholder}占位符,实现环境差异化。
4.3 Flyway 命令行基本操作
Flyway CLI 提供多个核心命令,用于管理数据库迁移全生命周期。以下为最常用的四个命令:
4.3.1 migrate —— 执行迁移
migrate 是 Flyway 最核心的命令,它会扫描所有未执行的迁移脚本,按版本号顺序依次执行,并将执行记录写入元数据表。
# 执行所有待迁移脚本
flyway migrate
# 指定目标版本(仅执行到 V2.0 为止)
flyway migrate -target=2.0
# 指定配置文件
flyway migrate -configFiles=./config/flyway.conf
4.3.2 info —— 查看迁移状态
info 命令用于查看当前数据库的迁移状态,包括已执行和待执行的脚本列表。输出结果以表格形式呈现,便于快速了解数据库版本演进情况。
flyway info
执行结果示例:
| Category | Version | Description | Type | Installed On | State |
|---|---|---|---|---|---|
| Versioned | 1.0 | Create user table | SQL | 2025-03-10 09:15:22 | Success |
| Versioned | 1.1 | Add email column | SQL | 2025-03-11 14:30:05 | Success |
| Versioned | 2.0 | Create order table | SQL | — | Pending |
4.3.3 validate —— 校验迁移脚本
validate 命令用于校验已执行的迁移脚本是否被篡改。Flyway 会重新计算每个已执行脚本的 checksum,与元数据表中的记录进行比对。如果发现不一致,则抛出异常,防止数据库状态与脚本不一致。
# 校验所有已执行脚本的完整性
flyway validate
# 校验并忽略迁移失败记录
flyway validate -ignoreMigrationPatterns=*:failed
重要提示:在生产环境中,建议将
validate 作为 CI/CD 流水线中 migrate 的前置步骤。如果校验失败,应中止流水线并人工介入排查脚本变更原因,避免因脚本篡改导致数据库状态不可控。
4.3.4 baseline —— 基线化
baseline 命令用于将现有数据库标记为某个版本,使 Flyway 能够从该版本开始管理后续迁移。这在以下场景中尤为关键:
- 现有数据库引入 Flyway:数据库已有表结构,但未使用 Flyway 管理。通过 baseline 将当前状态标记为基线版本,后续迁移脚本从基线版本之后开始执行。
- 跳过已有脚本:当迁移脚本已在其他环境执行过,但当前数据库的元数据表缺失时,使用 baseline 跳过已执行脚本。
# 将当前数据库标记为版本 1.0
flyway baseline -baselineVersion=1.0 -baselineDescription="Initial baseline"
# 使用配置文件中的 baseline 设置
flyway baseline
4.4 命令操作对比总结
| 命令 | 核心作用 | 执行频率 | CI/CD 集成建议 |
|---|---|---|---|
| migrate | 执行待迁移脚本,更新数据库 schema | 每次部署 | 作为部署流水线的核心步骤 |
| info | 查看迁移历史与当前状态 | 按需查询 | 用于流水线日志输出和状态报告 |
| validate | 校验已执行脚本的完整性 | 每次迁移前 | 作为 migrate 的前置检查步骤 |
| baseline | 初始化现有数据库的基线版本 | 首次接入时 | 用于新环境初始化或数据库重建 |
实践要点:
- 在 CI/CD 流水线中,建议按 validate → migrate → info 的顺序执行命令,确保迁移安全可控。
- 对于已有生产数据的数据库,首次引入 Flyway 时必须先执行
baseline,再执行migrate。 - 迁移脚本一旦提交并执行,禁止修改已发布的脚本内容。如需变更,应创建新的版本脚本。