将生产服务器代码推送到GitLab后，Django应用遇PostgreSQL迁移问题

一、先排查Python环境一致性问题 #

最初的No module named 'psycopg2'错误，大概率是WSGI服务器使用的Python环境与你执行pip3 install的环境不一致：

• 检查生产服务器是否使用了虚拟环境，若有，需激活虚拟环境后重新安装依赖：

  # 假设虚拟环境目录为venv
  source venv/bin/activate
  pip install psycopg2
  

• 重启WSGI服务（如uWSGI、Gunicorn或Apache），确保新安装的依赖被加载。

二、解决迁移历史不一致问题 #

InconsistentMigrationHistory错误是核心问题，说明admin应用的初始迁移早于你的app应用初始迁移被应用，打破了依赖顺序：

步骤1：备份数据库（必须操作） #

先备份生产数据库，避免数据丢失：

# PostgreSQL示例
pg_dump -U 用户名 数据库名 > backup.sql

或用Django自带的备份工具：

python3 manage.py dumpdata --exclude auth.permission --exclude contenttypes > backup.json

步骤2：修正迁移记录 #

进入Django数据库shell：

python3 manage.py dbshell

执行SQL删除admin应用的迁移记录：

DELETE FROM django_migrations WHERE app = 'admin';

退出数据库shell：

\q

步骤3：重新应用迁移 #

先fakeadmin的初始迁移（避免重复创建已有表），再应用app的迁移：

python3 manage.py migrate --fake admin 0001_initial
python3 manage.py migrate app

若你的app有后续迁移，直接执行全局迁移即可：

python3 manage.py migrate

三、验证页面访问量中间件功能 #

迁移完成后，检查app_pageview表是否存在：

python3 manage.py dbshell
\dt

确认表存在后，重启WSGI服务，测试网站是否恢复正常。

四、避免后续问题的建议 #

• 生产环境代码应通过Git拉取部署，而非直接在服务器上初始化Git仓库后上传，避免操作过程中误改配置。
• 统一使用虚拟环境管理依赖，确保WSGI服务与命令行使用的Python环境一致。
• 每次部署前，在测试环境验证迁移逻辑，避免直接在生产环境执行未验证的迁移操作。

内容的提问来源于stack exchange，提问作者carbontracking