理解sql-migrate并发迁移问题及解决方案

在分布式系统中使用sql-migrate进行数据库迁移时，开发人员可能会遇到一个常见问题：当多个应用实例同时启动并尝试执行迁移时，会导致迁移冲突。这种情况在生产环境中尤为常见，特别是在Kubernetes等容器编排平台上部署应用时。

问题本质

当多个pod或服务实例同时启动并执行sql-migrate迁移时，系统会尝试并行执行相同的迁移脚本。例如，一个简单的添加列操作：

alter table user_data
    add column version int8 not null default 1

如果两个实例同时执行这个迁移，第二个实例会遇到"column already exists"的错误，因为第一个实例已经成功添加了该列。这表明sql-migrate虽然会记录已执行的迁移，但在实际执行迁移脚本前没有足够的并发控制机制。

技术背景

sql-migrate的设计哲学是将迁移执行与并发控制分离。这是因为：

1. 某些数据库操作（如创建并发索引）无法在事务中执行
2. 不同的部署环境可能需要不同的并发控制策略
3. 迁移系统应保持简单，专注于迁移本身

解决方案

1. 使用分布式锁

最直接的解决方案是在应用层面实现分布式锁。在PostgreSQL中，可以使用咨询锁：

// 在运行迁移前获取锁
const svcMigrationsLock = 5309049090009123 // 随机固定数作为锁ID
_, err = db.Exec(fmt.Sprintf("select pg_advisory_lock(%d)", svcMigrationsLock))
if err != nil {
    return err
}
// 锁会在连接关闭时自动释放

2. 使用部署系统的钩子机制

在Kubernetes/Helm环境中，可以利用pre-upgrade hook确保迁移只运行一次：

# Helm pre-upgrade hook示例
annotations:
  "helm.sh/hook": pre-upgrade
  "helm.sh/hook-weight": "0"

3. 单次执行模式

对于简单部署，可以确保迁移只在特定实例上运行，例如：

• 主节点执行迁移
• 通过环境变量控制是否执行迁移
• 使用initContainer专门处理迁移

最佳实践建议

1. 环境考量：根据实际部署环境选择合适的并发控制方案
2. 迁移设计：将无法回滚的操作标记为notransaction，并特别注意其并发安全性
3. 监控机制：实现迁移状态的监控和告警
4. 文档记录：在团队内部明确迁移执行策略

总结

sql-migrate有意将并发控制留给使用者实现，这虽然增加了使用复杂度，但也提供了更大的灵活性。理解这一点后，开发者可以根据自己的系统架构选择最适合的解决方案，确保数据库迁移的安全性和可靠性。