不可能在没有任何SQL错误的情况下完成完美的Azure VIP交换

当网站被数量已经不多的+5用户使用，并且我进行VIP交换时，总会出现SQL错误，如：

System.Data.Entity.Core.EntityCommandExecutionException:执行命令定义时出错。有关详细信息，请参见内部异常。-->System.Data.SqlClient.SqlException:从服务器接收结果时发生传输级别错误。（提供程序：会话提供程序，错误：19-物理连接不可用）

我正在使用

SqlAzureExecutionStrategy

。此外，VIP交换期间的其他请求似乎需要约30秒的时间，使得站点实际上没有响应，尽管登台环境已经完全预热

• 有没有办法防止这种情况
• 我为什么不多读一些关于这种行为的书呢？其他人只是不关心一些中断的请求和缓慢的30秒时间，还是我在Sql/EF设置中遗漏了一些重要的东西

---

当一个站点正在积极生产时，您实际上是在交换实时代码。你肯定会遇到各种各样的错误。在服务不存在的情况下，总是会有一瞬间。部署新的sql模式时也是如此

你需要做的是意识到这将要发生，并围绕它进行设计。这里有一支强大的开发运营团队。我个人所做的是在不同的地理位置进行分阶段部署。当我升级东海岸时，我将让流量管理器将所有流量指向西海岸的web服务器。然后我把所有的交通都指向东海岸，同时更新西海岸。然后我将交通管理恢复正常

为了从东向西分配流量，通常使用traffic manager设置一个端点，该端点在后台指向正确的端点，就像代理一样。只需删除要升级的端点，这将强制重定向到活动站点。升级完成后，将端点添加回

---

您还应该确保代码能够很好地处理错误。例如，如果需要与外部系统同步，并且在升级过程中，在您的系统中输入了一条记录，但没有输入外部记录，那么是否可以使用您的数据重建外部系统的状态，反之亦然。

我终于采取措施，改用AzureWeb应用程序，而不是云服务，所有这些问题都得到了解决，甚至更多

这花了几天的时间，但绝对值得换换

---

为不小心让登台服务器打开而付费也是过去的问题。

我也对这种行为感兴趣。我认为瞬态故障处理可以解决这个问题，但仍然会写出错误。不，它没有。我自己也遇到过错误页面。所以我猜这也是一个时间问题。它似乎在交换负载平衡器上的VIP之前关闭了连接。我很想知道这是否也是Azure网站的一个问题。我曾与微软就交换部署时出现服务器500错误展开过一个案例，但由于我无法确定地再现错误，因此很难排除故障。Azure必须在vip交换发生之前关闭与SQL数据库的连接，然后在。。。如果你能始终如一地重现这个问题，我建议你在dcinzona打开一个问题清单。我肯定能重现这个问题。我从来没有想过开罚单，因为我只是一个小开发者，但也许我应该。无法想象所有begin公司都在接受这种atm机。我们现在在非工作时间安排VIP掉期，从技术上讲，这对我们来说是可行的，因为只有几秒钟的停机时间……也就是说，这是一个应该解决的问题。您是否有一些源代码可以始终如一地重现问题？我和大卫女士有一个支持计划，谢谢你的回答。不过，我并不真的同意你的观点。Azure在他们的文档中告诉我们，这只是一个简单的IP交换，外部IP的映射映射到另一个IP——任何服务都不应该停止。因此，在某种程度上，他们承诺完全按照您所描述的方式自动执行。我不认为这会对数据中心内部的通信产生什么影响。也就是说，我最终采取了转向Web应用程序而不是云服务的步骤，所有这些问题都得到了解决，等等。网络应用是一个伟大的产品。