Question

我正在使用“DATABASE_ROUTERS”，只是将迁移添加到新数据库。我在“默认”数据库上进行了153次迁移，似乎所有这些都必须在新数据库上运行，即使它们不适用。我的db路由器的allow_migrate在每次迁移时返回False，除了与新数据库相关的一个“初始”迁移。

我伪造了一个初始迁移然后运行manage.py migrate --database new_database并且惊讶地发现在45分钟后我不得不在用完所有内存和所有交换空间时终止进程！

然后我再次尝试，但这次是manage.py migrate --database new_database --fake，似乎没有任何区别。我的记忆和交换使用率已经达到顶峰，我不得不再次杀死这个过程。所有这个命令都应该在“django_migrations”表中将所有迁移标记为已完成。是什么导致使用这么多资源？我做错了吗？

解决此问题的最佳方法是什么？我应该手动创建“django_migrations”表，然后自己填充它吗？

Answer 1

如果有其他用户参与其中，我在这里解决了它（但它不是最理想的）。我基本上伪造了django_migrations表，因为实际上不需要在新数据库中进行迁移。

首先我查看＆＃34;默认＆＃34;数据库的django_migrations表，以查看第一次迁移是什么，然后通过命令行运行它以在新数据库中创建初始表。对我来说就是这样：

python manage.py migrate --database new_database --fake contenttypes 0001_initial

在我获得第一个初始值并创建表之后，我基本上使用SQL语句复制了其余的值。我确保保留＆＃34;默认＆＃34;的订单。数据库，如果有任何重要性。声明看起来像这样：

INSERT INTO django_migrations (app, name, applied) VALUES 
('auth', '0001_initial', NOW()),
('users', '0001_initial', NOW()),
  ...

然后为了确保一切顺利，我跑了：

python manage.py migrate --database new_database
python manage.py migrate

Django迁移速度缓慢且资源密集，即使使用“--fake”

1 个答案: