4

我一直致力于将两个遗留数据库中的 57k+ 条记录提炼和重构为一个与 Django 兼容的实体。现在，当我完成后，我将它作为固定装置转储，并尝试将其加载到生产环境中。

我的问题是该过程在短时间内被“杀死”。我的流程是：

./manage.py syncdb --noinput
./manage.py loaddata core/fixtures/auth.json  # just a default user
./manage.py migrate

结果：

Running migrations for django_extensions:  # custom apps migrate just fine
 - Migrating forwards to 0001_empty.
 > django_extensions:0001_empty
 - Loading initial data for django_extensions.
Installed 0 object(s) from 0 fixture(s)
Running migrations for myotherapp:
 - Migrating forwards to 0001_initial.
 > myotherapp:0001_initial
 - Loading initial data for myotherapp.
Installed 4 object(s) from 1 fixture(s)  # my other app with a fixture migrates ok
Running migrations for myapp:
 - Migrating forwards to 0001_initial.
 > myapp:0001_initial
 - Loading initial data for myapp.
Killed

我必须注意，这个过程在我的开发机器上没有问题。另一个注意事项是我的开发机器正在运行 postgres 9.2，在生产中有 9.1 - 这会是个大问题吗？

我该如何调试呢？我什至不知道打印模糊的“Killed”有什么问题。South 是否存储任何日志？任何帮助表示赞赏。

编辑：正如 Paulo Scardine 指出的那样，问题在于 JSON 文件太重。首先我尝试了 XML 转储，它走得更远，但最终也被杀死了。一种方法是 SQL 转储。对于 Postgres，对我有用的是：

pg_dump dbname | gzip > filename.gz # dump data on dev machine
createdb dbname # create empty db in production
gunzip -c filename.gz | psql dbname # restore the dump in production
4

1 回答 1

5

找不到有关加载固定装置的特定错误。这个是为了倾销，但我想根本原因是相关的：

您的问题有几个重复项：

当我遇到这个错误时，我被告知要改用 XML 固定装置，因为 XML 解析器在内存占用方面表现得更好。

我的建议是不要因为这个问题而失眠，如果可以的话，请使用普通的 SQL 转储。

于 2013-10-27T20:55:02.110 回答