使用Azure SQL数据库设计全球可用的服务

Question

我们正在使用SQL故障转移组，我碰到了this article，建议使用流量管理器和故障转移组构建一种可以在故障转移期间维持区域完整性的体系结构。我感兴趣的场景是场景1，它具有以下附图：

我知道实现区域完整性的其他方法，但是我很想了解在这种情况下如何做到这一点。有人可以说明方案1中的数据库区域与Web应用程序区域保持一致吗？该图显示两个区域都使用故障转移组的“读写”连接字符串。我的理解是，当区域A中的数据库报告问题时，区域A中的Web应用仍通过故障转移组的主要RW连接连接到区域A中的数据库，它将向流量管理器（TM）报告存在TM ping期间出现连接问题，因此区域A降级。

TM然后将流量定向到区域B。但是，区域B使用RW故障转移组连接字符串，因此它依赖于故障转移组切换到区域B中的DB。

我的困惑是：一旦故障转移组成功切换到区域B中的数据库，即主数据库服务器现在是区域B，是什么阻止TM切换回区域A中的Web应用程序？由于故障转移组已将其主数据库切换到了区域B中的数据库，因此区域A现在应该成功连接到数据库，因此应该向TM联机报告，但Web应用程序适当地不知道该数据库所在的区域，因为它位于故障转移组的后面，因此它应该仅报告成功的连接，从而使TM将流量引回到区域A，从而使体系结构处于跨区域状态，从而使解决方案的目的无效，即拥有所有资源可以在发生故障转移和故障回复时在单个区域内运行。

有人可以在这里解释如何维护区域完整性吗？

更新

经过一番挖掘，我发现this article似乎是对the other的补充。本文从VNET的角度描述了该问题，在VNET中，区域配置很重要。因此，在从VNET的角度来看的示例中：如果区域A中的DB失败导致故障切换到区域B中的DB，则故障转移组的RW节点将变为区域B，导致区域A失败-即区域A无法连接到区域B由于VNET规则；因此，整个系统将全部故障转移到Region B，并在Region A和Region B应用程序中维护RW节点，即不需要单独的数据库连接配置。当仅主数据库发生故障时，这将允许完整区域故障转移。这是文章中的相应部分：

  

在检测到中断时启动手动故障转移。此选项针对需要在前端和数据层之间保持一致的延迟的应用程序进行了优化，并在前端，数据层或两者都受中断影响时支持恢复。

据我所知，在故障转移组内的数据库发生故障的情况下，实现区域的完全故障转移并维护资源的区域配置，除了上图中的组件之外，还必须配置VNET和original article中详细介绍的步骤。似乎很明显，但仅阅读该页面并不清楚。如有其他意见，请提出建议。