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

【问题标题】：Django migration slow and resource intensive even with "--fake"即使使用“--fake”，Django 迁移缓慢且资源密集
【发布时间】：2018-04-16 07:20:49
【问题描述】：

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

我伪造了一个初始迁移，然后运行manage.py migrate --database new_database，令我惊讶的是，45 分钟后，当它用完所有内存和所有交换空间时，我不得不终止该进程！

然后我又试了一次，但这次是manage.py migrate --database new_database --fake，似乎没什么区别。我的内存和交换使用量激增，我不得不再次终止该进程。这个命令应该做的就是在“django_migrations”表中将所有迁移标记为已完成。究竟发生了什么导致如此多的资源被使用？我做错了吗？

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

【问题讨论】：

这个应用部署的地方多吗？如果没有部署需要所有这些旧迁移，您不妨压缩现有迁移或删除它们并构建闪亮的新最小迁移。 stackoverflow.com/questions/40028586/…
@HåkenLid - 在“默认”数据库上，只要运行一些新的迁移就没有问题。问题似乎是从头开始运行它。无论如何，“--fake”不应使用所有系统资源并占用超过 45 分钟。此外，一旦它最终完全运行，之后只需进行一些新的迁移就可以了。
我同意 --fake 花了这么长时间很奇怪。更有理由放弃这些迁移并重新开始。
就上下文而言，我们在部署时在 Django 项目上运行了大约 250 次迁移（包括在迁移中创建对象）。在我的机器上（有数据）大约需要 2 分钟，在服务器上大约需要 45 秒。在空数据库上大约 20 秒。转储和重建该数据库大约需要 6 分钟。
@Withnail - 我认为这可能是 Django 1.8 特有的问题（早期的颠覆存在问题）。你用的是哪个版本的 Django？

标签： python django postgresql django-migrations django-1.8

【解决方案1】：

万一其他用户遇到这个问题，这是我为解决它所做的（但这不是最理想的）。我基本上伪造了django_migrations 表，因为实际上不需要在新数据库中进行任何迁移。

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

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

在获得第一个初始值并创建表后，我基本上使用 SQL 语句复制了其余部分。我确保保留“默认”数据库中的订单以防万一。语句如下所示：

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

【讨论】：