<p>我认为这个问题有两个部分。</p>
<p>首先是管理数据库模式及其更改。我们使用South实现这一点,将工作模型和迁移文件保存在我们的SCM存储库中。为了安全(或偏执),我们在运行任何迁移之前(如果真的很害怕,在运行任何迁移之后)转储数据库。到目前为止,南方已经满足了我们的所有要求。</p>
<p>第二个是部署模式更改,这不仅仅是运行South生成的迁移文件。根据我的经验,对数据库的更改通常需要更改已部署的代码。如果您甚至有一个小的web服务器场,那么保持部署的代码与数据库架构的当前版本同步可能并不容易——如果考虑不同的缓存层并对已经处于活动状态的站点用户产生影响,情况会变得更糟。不同的网站处理这个问题的方式不同,我不认为有一刀切的答案。</p>
<hr/>
<p>解决这个问题的第二部分不一定是直截了当的。我不相信有一刀切的方法,也没有足够的信息,你的网站和环境,以建议一个解决方案,将最适合你的情况。不过,我认为在大多数情况下,有几个考虑因素可以帮助指导部署。</p>
<p>在某些情况下,使整个站点(web服务器和数据库)脱机是一个选项。这无疑是管理更新的最直接的方法。但是,频繁的停机(即使是在计划的情况下)可能是一种快速开展业务的好方法,使部署即使是很小的代码更改也很烦人,而且如果您有一个大型数据集和/或复杂的迁移,则可能需要花费数小时。也就是说,对于我帮助管理的站点(这些站点都是内部的,通常只在工作日的工作时间使用),这种方法会产生奇迹。</p>
<p>如果对主数据库的副本进行更改,请小心。这里的主要问题是您的站点仍然处于活动状态,并且可能接受对数据库的写操作。当您忙于迁移克隆以供以后使用时,写入主数据库的数据会发生什么情况?你的站点要么一直关闭,要么暂时处于只读状态,否则你会丢失它们。</p>
<p>如果您的更改是向后兼容的,并且您有一个web服务器场,有时您可以通过更新live production数据库服务器(我认为在大多数情况下这是不可避免的),然后通过将服务器场中的节点从负载平衡器中取出一段时间来增量地更新这些节点。这可以正常工作-但是这里的主要问题是,如果已经更新的节点发送了一个旧节点不支持的url请求,您将失败,因为您无法在负载平衡器级别管理该请求。</p>
<p>我听说有几种其他的方法很有效。</p>
<p>第一种方法是将所有代码更改包装到功能锁中,然后在运行时通过一些站点范围的配置选项对其进行配置。这实际上意味着您可以在关闭所有更改的地方发布代码,然后在对服务器进行所有必要的更新之后,更改配置选项以启用该功能。但这会产生很重的代码。。。</p>
<p>第二个是让代码管理迁移。我听说过一些站点,在这些站点中,对代码的更改是以这样一种方式编写的,即在运行时处理迁移。它能够检测正在使用的模式的版本,以及它返回的数据的格式—如果数据来自旧模式,它会就地执行迁移;如果数据已经来自新模式,它不会执行任何操作。从自然的站点使用情况来看,大部分数据将由使用站点的人迁移,其余的则可以随时使用迁移脚本。</p>
<p>但我认为在这一点上谷歌成为你的朋友,因为正如我所说,解决方案是非常有竞争力的我担心这个答案会变得毫无意义。。。搜索“零停机时间部署”之类的内容,您将得到诸如<a href="http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/">this</a>之类的结果,其中包含很多想法。。。</p>