问题描述

来自在非平凡生产环境中拥有 django 应用程序的人，您如何处理数据库迁移?我知道有south，但如果涉及任何实质性内容，似乎会错过很多.

From someone who has a django application in a non-trivial production environment, how do you handle database migrations? I know there is south, but it seems like that would miss quite a lot if anything substantial is involved.

其他两个选项(我能想到或已经使用)是在测试数据库上进行更改，然后(使用应用程序离线)并导入该 sql 导出.或者，也许是一个风险更大的选择，实时对生产数据库进行必要的更改，如果出现任何问题，则恢复到备份.

The other two options (that I can think of or have used) is doing the changes on a test database and then (going offline with the app) and importing that sql export. Or, perhaps a riskier option, doing the necessary changes on the production database in real-time, and if anything goes wrong reverting to the back-up.

您通常如何处理数据库迁移和架构更改?

How do you usually handle your database migrations and schema changes?

推荐答案

我认为这个问题有两个部分.

I think there are two parts to this problem.

首先是管理数据库架构及其更改.我们使用 South 执行此操作，将工作模型和迁移文件都保存在我们的 SCM 存储库中.为了安全(或偏执)，我们在运行任何迁移之前(如果我们真的很害怕，那么之后)会转储数据库.到目前为止，South 已经足以满足我们的所有要求.

First is managing the database schema and it's changes. We do this using South, keeping both the working models and the migration files in our SCM repository. For safety (or paranoia), we take a dump of the database before (and if we are really scared, after) running any migrations. South has been adequate for all our requirements so far.

其次是部署架构更改，这不仅仅是运行 South 生成的迁移文件.根据我的经验，更改数据库通常需要更改已部署的代码.如果您甚至有一个小型网络农场，保持已部署的代码与您的数据库模式的当前版本同步可能并非易事 - 如果您考虑不同的缓存层和对已经活跃的站点用户的影响，这会变得更糟.不同的网站处理这个问题的方式不同，我认为没有一个万能的答案.

Second is deploying the schema change which goes beyond just running the migration file generated by South. In my experience, a change to the database normally requires a change to deployed code. If you have even a small web farm, keeping the deployed code in sync with the current version of your database schema may not be trivial - this gets worse if you consider the different caching layers and effect to an already active site user. Different sites handle this problem differently, and I don't think there is a one-size-fits-all answer.

解决这个问题的第二部分不一定是直截了当的.我不相信有一种万能的方法，并且没有足够的关于您的网站和环境的信息来建议最适合您的情况的解决方案.不过，我认为有一些注意事项可以帮助指导大多数情况下的部署.

Solving the second part of this problem is not necessarily straight forward. I don't believe there is a one-size-fits-all approach, and there is not enough information about your website and environment to suggest a solution that would be most suitable for your situation. However, I think there are a few considerations that can be kept in mind to help guide deployment in most situations.

在某些情况下，使整个站点(Web 服务器和数据库)脱机是一种选择.这无疑是管理更新最直接的方式.但是频繁的停机(即使是计划好的)可能是快速开展业务的好方法，即使是很小的代码更改也会让人厌烦，如果您有大型数据集和/或复杂的迁移，可能需要很多小时.也就是说，对于我帮助管理的网站(这些网站都是内部的，通常只在工作日的工作时间使用)，这种方法效果很好.

Taking the whole site (web servers and database) offline is an option in some cases. It is certainly the most straight forward way to manage updates. But frequent downtime (even when planned) can be a good way to go our of business quickly, makes it tiresome to deploy even small code changes, and might take many hours if you have a large dataset and/or complex migration. That said, for sites I help manage (which are all internal and generally only used during working hours on business days) this approach works wonders.

如果您在主数据库的副本上进行更改，请务必小心.这里的主要问题是您的站点仍然存在，并且可能正在接受对数据库的写入.当您忙于迁移克隆以供以后使用时，写入主数据库的数据会发生什么情况?您的网站要么一直处于关闭状态，要么暂时处于只读状态，否则您将丢失它们.

Be careful if you do the changes on a copy of your master database. The main problem here is that your site is still live, and presumably accepting writes to the database. What happens to data written to the master database while you are busy migrating the clone for later use? Your site has to either be down the whole time or put in some read-only state temporarily otherwise you'll lose them.

如果您的更改是向后兼容的，并且您有一个网络场，则有时您可以避免更新实时生产数据库服务器(我认为在大多数情况下这是不可避免的)，然后通过获取它们来增量更新场中的节点在短时间内离开负载均衡器.这可以正常工作 - 但是这里的主要问题是，如果一个已经更新的节点发送一个旧节点不支持的 url 请求，您将失败，因为您无法在负载均衡器级别进行管理.

If your changes are backwards compatible, and you have a web farm, sometimes you can get away with updating the live production database server (which I think is unavoidable in most situations) and then incrementally updating nodes in the farm by taking them out of the load balancer for a short period. This can work ok - however the main problem here is if a node that has already been updated sends a request for a url which isn't supported by an older node you will get fail as you cant manage that at the load balancer level.

我已经看到/听到了其他几种效果很好的方法.

I've seen/heard a couple of other ways work well.

第一个是将所有代码更改包装在一个功能锁中，然后可以在运行时通过一些站点范围的配置选项进行配置.这实质上意味着您可以在关闭所有更改的情况下发布代码，然后在对服务器进行所有必要的更新后，您可以更改配置选项以启用该功能.但这会产生相当繁重的代码......

The first is wrapping all code changes in a feature lock which is then configurable at run-time through some site-wide configuration options. This essentially means you can release code where all your changes are turned off, and then after you have made all the necessary updates to your servers you change your configuration option to enable the feature. But this makes quite heavy code...

第二个是让代码管理迁移.我听说过一些网站，其中对代码的更改是以在运行时处理迁移的方式编写的.它能够检测正在使用的模式的版本，以及它返回的数据的格式——如果数据来自旧模式，它会就地迁移，如果数据已经来自新模式，它什么也不做.从自然站点使用情况来看，您的大部分数据将由使用该站点的人迁移，其余的您可以随时使用迁移脚本来完成.

The second is letting the code manage the migration. I've heard of sites where changes to the code is written in such a way that it handles the migration at runtime. It is able to detect the version of the schema being used, and the format of the data it got back - if the data is from the old schema it does the migration in place, if the data is already from the new schema it does nothing. From natural site usage a high portion of your data will be migrated by people using the site, the rest you can do with a migration script whenever you like.

但我认为此时谷歌成为你的朋友，因为正如我所说，解决方案是非常特定于上下文的，我担心这个答案会开始变得毫无意义......搜索零停机时间部署"之类的内容你会得到诸如 this 有很多想法...

But I think at this point Google becomes your friend, because as I say, the solution is very context specific and I'm worried this answer will start to get meaningless... Search for something like "zero down time deployment" and you'll get results such as this with plenty of ideas...

这篇关于django 生产环境中的数据库迁移的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！