我设置了两个Azure网站--一个不使用数据库为客户端应用程序提供服务,另一个使用数据库和WebApi解决方案,客户端可以从中获取数据。
我将向数据库中添加一个新表,并使用一个只计划运行一次的临时种子方法填充数据。不过,我不确定最好的方法是什么。
一切似乎都很顺利,但是update / seed方法需要大约6分钟才能运行。在迁移时,我有一些关于并发性的问题:
当业务逻辑和表在这6分钟内更新时,如果有人对数据库执行CRUD操作,会发生什么情况?我的意思是-从我从VS点击“发布”到实际部署新的bits之间的时间。如果seed方法修改了另一个表中的每个条目,并且用户添加了一些未被此关键更新命中的数据,该怎么办?我是不是应该在做的时候锁定网站以防万一(远非理想的……)?
任何关于此过程的一般指导都将是非常棒的。
发布于 2013-07-24 03:39:49
像创建新表或添加新列这样的操作对性能的影响应该很小,并且应该是透明的,特别是如果应用程序应用了处理瞬时故障的推荐模式(例如,通过利用Enterprise Library)。
大量更新或重新索引可能会导致争用,影响应用程序的性能,甚至会导致错误。根据情况的不同,瞬时故障处理也可以解决这个问题。
对正在升级的数据进行并发修改可能会导致更难以处理的问题。以下是一些可能的方法:
维护窗口
最简单和安全的方法是使应用程序脱机,备份数据库,升级数据库,更新应用程序,测试并使应用程序恢复在线。
只读模式
这种方法使应用程序保持在线,但禁用任何更改数据库的功能,从而避免应用程序完全不可用。当应用程序更新时,用户仍然可以查询和查看数据。
Staged
这种方法基于对数据库结构和数据以及应用程序代码的精心计划的更改序列,以便在任何给定的阶段,在线的应用程序版本都与当前的数据库结构兼容。
例如,假设我们需要向客户记录引入“上次购买日期”字段。可以使用以下序列:
这种方法有几种变体,例如Zero-Downtime Database Deployment中描述的“扩展脚本”和“收缩脚本”的概念。这可以与feature toggles一起使用,在执行升级阶段时动态地更改应用程序的行为。
可以将新列添加到记录中,以指示它们已被转换。应用程序逻辑可以调整为同时处理旧版本和新版本中的记录。
实体框架可能会在选项中施加一些额外的限制,因为它代表应用程序生成SQL语句,因此您在规划阶段时必须考虑到这一点。
转移环境
更改生产数据库结构和执行大量数据更改是一项有风险的业务,尤其是在用户输入和更改数据时必须按特定顺序进行更改的情况下。您恢复错误的选择可能会受到严重限制。
在生产环境中执行升级过程之前,需要在单独的试运行环境中进行广泛的测试和模拟。
发布于 2013-07-30 03:40:32
我同意Fernando提出的维护窗口的想法。但对于您的问题,以下是我将采取的方法。
主要的事情是通过实体框架使用seed方法,它很容易出错,并且在运行Prod时如果没有适当的备份,你可能很快就会陷入麻烦。我可能会先在您的测试数据库/环境中运行它(如果您有的话),以验证您想要发生的事情。
https://stackoverflow.com/questions/17769194
复制相似问题