【发布时间】:2016-04-21 16:36:58
【问题描述】:
与this question 一样,我为我的数据库设置了一个基于dumpdata 的备份系统。该设置类似于运行一个调用dumpdata 并将备份移动到远程服务器的cron 脚本,目的是简单地使用loaddata 来恢复数据库。但是,我是not sure this plays well with migrations。 loaddata 现在有一个 ignorenonexistent 开关来处理已删除的模型/字段,但它无法解决使用一次性默认值添加列或应用 RunPython 代码的情况。
在我看来,有两个子问题需要解决:
- 使用每个应用的当前版本标记每个
dumpdata输出文件 - 将固定装置拼接到迁移路径中
我对如何在不引入大量开销的情况下解决第一个问题感到困惑。每次备份保存一个包含{app_name: migration_number} 映射的额外文件就足够了吗?
第一个问题解决后,我认为第二个问题会更容易,因为过程大致是:
- 创建一个新数据库
- 将迁移向前运行到每个应用的适当点
- 使用给定的夹具文件调用
loaddata - 运行其余的迁移
this question(链接自错误报告)中有一些我认为可以用于此目的的代码。
由于这些是数据库的相当常规/大的快照,我不想将它们作为数据迁移保留在迁移目录中。
【问题讨论】:
-
这不能回答您的问题,但我发现使用数据库转储是一种非常简单的备份解决方案。我对 Postgres 使用
pg_dump,对 MySQL 数据库使用mysqldump。 -
如何更简单?如果您在备份后应用迁移,您最终不会遇到同样的问题吗?
-
您的数据库转储包含数据库的完整副本。这包括
django_migrations表。在数据库转储之前创建的迁移将不会再次运行,只会运行比数据库转储更新的迁移。
标签: python django backup django-migrations dumpdata