Django迁移文件丢失 数据库已应用变更无对应迁移文件如何处理？

核心问题说明 #

当前状态为：PostgreSQL库中已存在0004_auto_20210707_2039的迁移记录，且表结构已经完成对应变更，但本地/线上代码库中缺少该迁移文件，导致showmigrations无法识别该迁移，后续部署会出现迁移状态冲突。 #

操作步骤 #

1. 本地生成匹配的迁移文件 #

• 确保本地redirect应用的models.py代码和你当时推送至线上的代码版本完全一致（仅包含当时新增的字段改动，无后续额外修改）
• 本地执行命令：

  python manage.py makemigrations redirect
  

• 到redirect/migrations/目录下找到新生成的0004迁移文件，务必核对文件内的操作仅包含你当时新增的字段变更，无多余的增删改操作
• 将该迁移文件重命名为和数据库记录完全一致的名称：0004_auto_20210707_2039.py

2. 校验迁移合法性 #

• 本地执行命令查看迁移对应的SQL：

  python manage.py sqlmigrate redirect 0004
  

• 确认输出的SQL和你实际线上表结构的变更完全匹配，无冲突

3. 同步迁移状态（无数据风险） #

migrate --fake的作用仅为修改django_migrations表中的迁移状态标记，不会实际执行SQL修改表结构，不会影响现有业务数据，可以放心执行：

• 将重命名后的0004迁移文件提交到版本控制系统，推送至线上部署
• 线上容器更新代码后，执行命令：

  python manage.py migrate --fake redirect 0004
  

• 执行完成后运行python manage.py showmigrations，即可看到0004_auto_20210707_2039的状态变为已勾选，和数据库记录完全同步

后续规避规则 #

• 禁止直接在生产Docker容器内执行makemigrations：Docker容器默认使用临时文件系统，容器销毁/重建后生成的迁移文件会直接丢失，这是你之前操作后未留存迁移文件的根本原因
• 所有迁移文件必须在本地生成、校验后提交至版本库，走正规CI/CD流程部署后再执行migrate操作

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