Dav*_*542 17 python mysql migration django django-south
对于在非平凡的生产环境中拥有django应用程序的人,您如何处理数据库迁移？我知道有south,但如果涉及任何实质性的事情,似乎会错过很多.
另外两个选项(我能想到或已经使用过)是在测试数据库上进行更改,然后(使用应用程序脱机)并导入该sql导出.或者,也许是一个风险更高的选择,实时对生产数据库进行必要的更改,如果出现任何问题,还原为备份.
您通常如何处理数据库迁移和架构更改？
Mar*_*eld 16
我认为这个问题有两部分.
首先是管理数据库模式及其变化.我们使用South执行此操作,将工作模型和迁移文件保留在SCM存储库中.为了安全(或偏执),我们在运行任何迁移之前(如果我们真的害怕,之后)进行数据库转储.到目前为止,南方已满足我们的所有要求.
其次是部署架构更改,这不仅仅是运行South生成的迁移文件.根据我的经验,对数据库的更改通常需要更改已部署的代码.如果您有一个小型Web场,那么将部署的代码与当前版本的数据库架构保持同步可能并不简单 - 如果考虑不同的缓存层并对已经活动的站点用户产生影响,这会变得更糟.不同的网站以不同的方式处理这个问题,我认为没有一个通用的答案.
解决这个问题的第二部分并不一定是直截了当的.我不相信有一种通用的方法,并且没有足够的关于您的网站和环境的信息来建议最适合您情况的解决方案.但是,我认为可以记住一些注意事项,以帮助指导大多数情况下的部署.
在某些情况下,将整个站点(Web服务器和数据库)脱机是一种选择.它当然是管理更新的最直接方式.但是频繁的停机时间(即使在计划中)也是快速开展业务的好方法,使得部署甚至很少的代码变得令人厌烦,如果您拥有大型数据集和/或复杂的迁移,可能需要花费数小时.也就是说,对于我帮助管理的网站(这些网站都是内部网站,通常仅在工作日的工作时间使用),这种方法可以实现奇迹.
如果对master数据库的副本进行更改,请务必小心.这里的主要问题是您的网站仍然存在,并且可能接受对数据库的写入.当您忙于迁移克隆以供以后使用时,写入主数据库的数据会发生什么变化？您的网站必须暂时停止或暂时处于某种只读状态,否则您将丢失它们.
如果您的更改是向后兼容的,并且您有一个Web场,有时您可以更新实时生产数据库服务器(我认为在大多数情况下这是不可避免的),然后逐步更新服务器场中的节点负载平衡器短期.这可以正常工作 - 但是这里的主要问题是,如果已经更新的节点发送了对旧节点不支持的URL请求,您将无法在负载均衡器级别管理该节点.
我已经看到/听到过其他几种方法.
第一种是将所有代码更改包装在功能锁中,然后通过某些站点范围的配置选项在运行时进行配置.这实际上意味着您可以释放所有更改都已关闭的代码,然后在对服务器进行所有必要的更新后,更改配置选项以启用该功能.但这使得代码相当繁重......
第二个是让代码管理迁移.我听说过这样的站点,其中代码的更改以这样的方式编写,即它在运行时处理迁移.它能够检测正在使用的模式的版本,以及它获取的数据的格式 - 如果数据来自旧模式,它就会进行迁移,如果数据已经来自新模式,它什么也不做.从自然站点使用中,大部分数据将由使用该站点的人员迁移,其余的您可以随时使用迁移脚本进行迁移.
但我认为此时谷歌会成为你的朋友,因为正如我所说,解决方案是针对特定情况的,我担心这个答案会变得毫无意义......搜索"零停机时间部署"和"你"将获得的结果,如这与很多的想法......