在Heroku上,在实例已经使用更改的模型代码重新启动后,Django syncdb/South迁移是否存在危险？

Question

在Heroku上,只要您推送新代码,即使尚未应用基础数据库架构添加/更改(通过syncdb或南迁移),Web服务实例也会重新启动.

在许多情况下,这可能只会导致无害的错误,并且很快就会运行syncdb/migrate.但是我担心在某些情况下,新代码可能会在迁移前数据库中进行意外更改.

什么是安全抵御这种风险的正确方法？

一种技术可能是将syncdb/migrate添加到Procfile,以便在web重启之前运行.但是,在多个实例的情况下,或者甚至可能是一个旧的代码实例一直运行直到一个新的代码实例被知道的情况下,仍然存在一个问题的变体,其中代码是与具有不匹配架构的DB交谈.

是否存在"保留所有Web实例"功能(或常见的最佳实践),以便在没有Web流量的情况下完成迁移？

或者我过度担心在实践中可以忽略不计的风险？

Answer 1

处理这种性质的迁移的最安全的方法,Heroku或否,是严格采用与您的模式和代码的兼容性方法:

• 每个添加或变换架构更改必须向后兼容;
• 必须在删除依赖于它的代码后执行每个破坏性模式更改;
• 每个代码更改必须是:
  • 对于尚未进行关联模式更改的可能性持久(例如,删除模型或模型上的字段)或
  • 仅在执行关联的模式更改(在模型上添加模型或字段)之后才进行

如果需要对模型进行重大转换,则此方法可能需要执行以下步骤:

• 创建新的数据库表以保存新的模型结构,并部署该迁移
• 使用新结构创建新模型,并在旧模型更改时将更改从旧模型复制到新模型,并部署该代码
• 执行迁移或代码操作以将所有旧模型数据复制到新模型
• 更新代码库以使用新模型而不是旧模型,删除旧模型并部署该代码
• 执行迁移以从数据库中删除旧模型结构

通过一些思考和计划,它也可以用于更激烈的变化:

• 部署代码完全消除对数据库某一部分的依赖,可能会用维护页面替换站点的那些部分
• 部署迁移,进行大幅度的更改,不会出于任何原因使用上述双模型工作流程
• 部署代码,使受影响的部分恢复,并支持新的模型结构

这可能很难组织,并且需要严格的规范和对代码与数据库交互的牢固理解,但实际上,它确实允许进行大多数更改,而不会比服务器重启本身强加的停机时间更长.