flyway执行无限等待

目录

前言

migration

CONCURRENTLY

造成的原因

根本原因

现象

解决方式

方法1（官方推荐）

方法2

方法3（更稳定）

前言

很多团队在用Flyway + PostgreSQL做数据库迁移时，都遇到过一个非常诡异的问题：

• flyway migrate一直卡住

• 没有报错

• 数据库 CPU / IO 都很低

• 日志也没有异常

看起来就像Flyway 死锁了。

如果你的 migration 里用了CONCURRENTLY创建索引，那你很可能踩中了 Flyway 的一个经典坑。

migration

**Migration（数据库迁移）**在软件开发里指的是：

用代码的方式管理数据库结构的变更。

简单说就是：

数据库结构的“版本升级”。

CONCURRENTLY

CONCURRENTLY是 PostgreSQL 里的一个关键字，意思是：

并发执行（不锁表）

最常见用在 创建索引和删除索引 时，让数据库在操作期间 仍然可以读写数据。

造成的原因

1.在线索引+flyway卡住

2.两个migration 并且都是非事务 SQL

典型场景： 1️⃣ 第一个 migration 是 非事务 SQL -- flyway:executeInTransaction=false CREATE INDEX CONCURRENTLY idx_a ON table_a(col); 2️⃣ 第二个 migration 也是 非事务 SQL -- flyway:executeInTransaction=false CREATE INDEX CONCURRENTLY idx_b ON table_b(col); 运行： flyway migrate 结果： 第一条执行成功 第二条开始后一直卡住 不会报错 不会结束 看起来像：卡住

根本原因

Flyway 9 的锁机制

Flyway 9.x + PostgreSQL 在线索引卡住的根本原因： Flyway schema lock + PostgreSQL CONCURRENTLY 需要等待事务 + migration 连接未释放 = 第二个 migration 无限等待

现象

• migration 一直卡住

• 没有报错

• 数据库 CPU、IO 都很低

• 日志也没有任何异常

解决方式

方法1（官方推荐）

把在线索引放在单独 migration

-- flyway:executeInTransaction=false CREATE INDEX CONCURRENTLY idx_a ON table_a(col);

只放一条语句。

方法2

在 migration 之间加checkpoint migration

V10__index_a.sql V11__noop.sql V12__index_b.sql

V11：

SELECT 1;

方法3（更稳定）

使用：

flyway.group=false

避免多个 migration 合并执行。