我有一个有状态服务，它使用 Azure 存储帐户为 RunAsync 上的主副本配置状态备份。
有一天，有人无意中删除了用于备份的存储帐户。在我们的下一次部署中，由于此 404 错误响应，服务在初始化时开始抛出错误。
我注意到，在部署过程中，结构显然会围绕旧版本的服务进行调整，根据需要启动新的主服务器，以释放正在升级的虚拟机。如果旧版本的代码抛出异常无法实例化，升级过程将失败导致回滚。
我的问题是，一旦我创建了一个新的存储帐户，我似乎仍然无法将现有服务恢复到正常状态。我现有的服务正在使用存储帐户 URL 和不再存在于 azure 中的 AccountKeys。升级尝试失败，因为旧的服务实例由于现在配置错误而无法实例化。
有什么办法可以处理这种情况吗？
答案 0 :(得分：1)
最简单的方法是使用 unmonitored manual 升级强制完成将服务指向新存储帐户的更改。
但是，这会给您带来大量管理开销，尤其是在有许多其他服务的情况下，因为您需要小心地手动执行所有安全和功能检查，以免出现任何倒退。
推荐的解决方案是使用 here 描述的 ServiceTypeHealthPolicyMap 来“屏蔽”不健康的服务（因为您预计它在升级过程中会不健康）。您可能还需要根据具体情况调整其他一些升级参数。
第三个建议，或者将来可能需要改进的地方，是将更改帐户信息的升级升级为仅配置升级。这将确保 SF 尝试在不重新启动服务的情况下就地更改配置（默认情况下），这将防止现有服务在升级期间进行故障转移并遇到问题。这在 this example 中进行了演示。