Question

我想通过运行Migration.backwards()方法恢复上次迁移（0157）。由于我要恢复生产服务器中的迁移，我想在代码部署期间自动运行它。部署脚本执行以下步骤：

拉代码更改
运行迁移：manage.py migrate <app>
刷新Apache以使用最新代码：touch django.wsgi

如果可以，我会创建新的迁移文件，这会告诉South向后迁移到0156：

migrations/0158_backward__migrate_to_0156.py

此提交的迁移将部署到生产并在manage.py migrate <app>命令期间执行。在这种情况下，我不必像these answers中建议的那样手动执行向后迁移。

让我们说，我创建了两次数据迁移，第一次是用户付款，第二次是用户模型。我已经为迁移实现了backwards（）方法，以防我必须恢复这些数据迁移。我已将这两个迁移部署到生产中。并突然发现付款迁移包含错误。我想尽快恢复我最近的两次数据迁移。最安全的方法是什么？

Answer 1

由于我要恢复生产服务器中的迁移，我想运行在代码部署期间自动执行。

恕我直言，最安全的道路是

运行manage.py migrate <app>（即应用所有现有迁移，即最多0156）
撤消模型中的更改
运行manage.py schemamigration <app> --auto

这将创建一个新的迁移0157，它可以有效地恢复先前的迁移0156.然后，只需再次运行manage.py migrate <app>即可应用新的迁移。据我了解，您的代码部署就是这样做的。

Answer 2

这里没有银弹。我能想到的最简单的解决方案是 - 在您的开发环境中 - 当然 - 手动迁移回0156，手动更新您的迁移历史表（抱歉我现在不记得表的名称）愚弄南方认为你是仍然是@ 0158，然后再次运行schemamigration。不保证工作，但可能值得尝试。

Answer 3

显然，代码行的迁移速度高达＃157，现在开发人员认为最后一个不是一个好主意。所以计划是回到＃156。

两种情况：

（a）迁移＃157尚未在任何地方发布或部署。只需从models.py恢复最后一个更改，然后从源存档中删除迁移＃157.py。任何部署都会使系统达到156级; “157从未出现过。”

（b）已经部署了迁移＃157的最新软件。在这种情况下，先前的策略显然不起作用。因此，您需要创建迁移＃158以撤消＃157。还原models.py中的更改并运行

django manage.py migrate <app> 0157
django manage.py schemamigration <app> --auto

这将自动生成一个新的迁移＃158，它将包含与＃157相比的反向模式迁移。

如果由于django模型验证而导致schemamigration出现问题（如果您有自定义验证器可以检查ORM框外部的内容，则可能会发生这种情况），我建议采用以下解决方法：

<django project>/<app>/management/commands/checkmigrations.py

from south.management.commands import schemamigration
class Command(schemamigration.Command):
    requires_model_validation = False
    help = "schemamigration without model validation"

此命令在manage.py中可用：

django manage.py checkmigrations <app> --auto

南：如何在生产服务器中恢复迁移？

3 个答案: