Dawarich项目数据库迁移问题分析与解决方案

问题背景

在Dawarich项目的0.19.5版本中，用户报告了一个严重的数据库迁移问题。当系统启动时，多个容器同时尝试执行数据库迁移操作，导致并发冲突，最终使整个系统陷入崩溃循环状态。这个问题在0.19.4版本中首次出现，并延续到0.19.5版本。

问题现象

系统启动时，主要表现出以下症状：

1. 数据库迁移过程中出现ActiveRecord::ConcurrentMigrationError错误
2. 错误信息明确指出"无法运行迁移，因为另一个迁移进程正在运行"
3. 系统容器不断重启，形成崩溃循环
4. 某些数据迁移操作耗时极长(超过20分钟)

技术分析

问题的核心在于PostgreSQL的咨询锁(advisory lock)机制。当Dawarich系统启动时：

1. 主应用容器和Sidekiq工作容器同时启动
2. 两者都尝试执行数据库迁移操作
3. PostgreSQL通过咨询锁防止并发迁移
4. 其中一个进程获取锁后，另一个进程立即失败
5. 失败导致容器重启，形成循环

此外，某些数据迁移操作(如反向地理编码更新)设计上需要处理大量数据，导致执行时间过长(20分钟以上)，这进一步加剧了问题。

解决方案

经过社区讨论和测试，确定了以下解决方案：

1. 手动干预：对于已经出现问题的系统

   • 停止所有容器
   • 手动检查并释放PostgreSQL中的咨询锁
   • 按顺序启动容器(先主应用，后Sidekiq)

2. 架构改进：

   • 将耗时长的数据迁移操作改为后台任务
   • 确保未来所有数据迁移都在后台执行
   • 改进Sidekiq启动逻辑，使其能等待主应用完成迁移

3. 用户体验优化：

   • 主应用在迁移期间应显示"数据库升级中"状态
   • 确保Web界面返回200状态码而非5xx错误

最佳实践建议

对于使用Dawarich系统的管理员：

1. 执行大版本升级时，预留足够的处理时间
2. 监控数据库迁移进度，不要过早干预
3. 按照正确顺序启动容器服务
4. 对于生产环境，考虑在低峰期执行升级

总结

Dawarich项目的这次数据库迁移问题展示了分布式系统中数据一致性的挑战。通过分析咨询锁冲突和优化迁移策略，项目团队不仅解决了眼前的问题，还改进了系统架构，为未来的平滑升级奠定了基础。这种问题在包含数据库迁移的分布式系统中相当典型，其解决方案对其他类似项目也有参考价值。