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

Question

我们正在使用 SQL 故障转移组，我看到这篇文章建议可以使用流量管理器和故障转移组构建一个在故障转移期间保持区域完整性的体系结构。我感兴趣的场景是场景 1，它有这个附图：

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

然后，TM 会将流量引导到区域 B。但是，区域 B 正在使用 RW 故障转移组连接字符串，因此它依赖于故障转移组切换到区域 B 中的数据库。

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

有人可以解释一下如何在这里保持区域完整性吗？

更新

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

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

因此，据我所知，要实现区域的完全故障转移并在故障转移组内的数据库发生故障时保持区域资源配置，除了上图中的组件和详细步骤之外，您还必须配置 VNET在原文中。似乎很明显，但仅阅读该页面并不清楚。如果有其他意见请指教。

标签： sql-serverazurefailoverdisaster-recoveryazure-traffic-manager