解决Django数据库迁移错误与Label Studio部署问题

1. 问题背景与错误解析

最近在部署Label Studio时遇到了一个典型的Django数据库迁移错误：django.db.utils.OperationalError: table "labels_manager_label" already exists。这个错误表面上看是表已存在，但背后隐藏着更深层次的Django迁移机制和容器化部署问题。

错误堆栈显示，当Django尝试执行create_model操作时，SQLite数据库已经存在同名表。这种情况通常发生在：

1. 数据库迁移文件(migration)被重复执行
2. 多个进程同时尝试初始化数据库
3. 数据库文件被意外保留导致状态不一致

特别注意：在SQLite环境下，数据库文件是以单个文件形式存在的，这使其对并发写入特别敏感。当多个Django进程同时尝试执行迁移时，极易出现这种锁定冲突。

2. 错误根源深度分析

2.1 多进程冲突机制

Label Studio使用Django作为后端框架，其标准启动流程包含以下关键步骤：

1. 检查数据库连接
2. 应用未执行的迁移文件
3. 创建必要的数据库表结构
4. 启动开发服务器

当我们在容器中执行以下操作序列时就会触发问题：

bash复制# 容器自动执行的启动命令（进程A）
label-studio start --no-browser 

# 然后我们手动执行的命令（进程B）
docker exec -it container_name label-studio start

两个进程会同时尝试初始化相同的SQLite数据库文件，而SQLite的写入锁机制无法有效处理这种冲突。

2.2 Django迁移系统工作原理

Django的迁移系统通过django_migrations表记录已应用的迁移。当出现"table already exists"错误时，通常意味着：

1. 数据库中存在物理表
2. 但django_migrations表中缺少对应记录
3. 或者迁移文件被修改后重新执行

这种情况会导致Django的迁移状态与实际数据库结构不同步。

3. 完整解决方案

3.1 彻底清理环境

首先需要确保完全清理旧环境：

bash复制# 停止并删除容器
d