使用 Azure SQL 数据库设计全球可用的服务
适用于：
Azure SQL 数据库
通过 Azure SQL 数据库生成和部署云服务时，可使用活动异地复制或故障转移组在发生区域性中断和灾难性故障时进行复原。 通过此功能，还可创建针对数据的本地访问进行了优化的全球分布式应用程序。 本文讨论了常见的应用程序模式，包括每种模式的优势和考量因素。
注意
如果正在使用“高级”或“业务关键”数据库和弹性池，可以通过将它们转换为区域冗余部署配置，使它们能够适应区域性的中断。 请参阅区域冗余数据库。
应用场景 1：使用两个 Azure 区域来实现业务连续性，同时将停机时间减至最小
在此方案中，应用程序具有以下特征：
- 应用程序在一个 Azure 区域中处于活动状态
- 所有数据库会话需要数据读取和写入权限 (RW)
- 必须并置 Web 层和数据层以减少延迟和流量成本
- 从根本上讲，相比数据丢失，停机时间对于那些应用程序来说是更高的业务风险
在这种情况下，当所有应用程序组件需要一同进行故障转移时，将针对处理区域灾难对应用程序部署拓扑进行优化。 下图展示了此拓扑。 为了实现地理冗余，应用程序的资源会部署到区域 A 和 B。但是，只有当区域 A 故障后才会利用区域 B 中的资源。 两个区域之间会配置故障转移组，用于管理数据库连接、复制和故障转移。 两个区域中的 Web 服务配置为通过读写侦听器 <failover-group-name>.database.chinacloudapi.cn 访问数据库 (1)。 Azure 流量管理器设置为使用优先级路由方法 (2)。
注意
Azure 流量管理器在本文中仅供说明之用。 可以使用任何支持优先级路由方法的负载均衡解决方案。
下图显示了在发生服务中断之前的此配置：
主要区域服务中断后，SQL 数据库会检测到主数据库不可访问，并基于自动故障转移策略 (1) 的参数触发到次要区域的故障转移。 可以配置一个宽限期来控制断电检测和故障转移本身之间的时间，具体取决于应用程序 SLA。 Azure 流量管理器可能会在故障转移组触发数据库的故障转移前启动终结点故障转移。 在这种情况下，Web 应用程序无法立即重新连接到数据库。 但在数据库故障转移完成后，会立即自动实现重新连接。 当失败的区域还原并恢复联机状态时，旧的主数据库自动作为新的辅助数据库进行重新连接。 下图显示故障转移后的配置。
注意
故障转移后提交的事物会在重新连接时丢失。 故障转移完成后，区域 B 中的应用程序能重新连接并重新开始处理用户请求。 现在 Web 应用程序和主数据库均位于区域 B 并始终存在于同一位置。
如果区域 B 中发生中断，那么主数据库和辅助数据库之间的复制进程会挂起，但是两者之间的链接不会受影响 (1)。 流量管理器检测到区域 B 的连接中断，并将终结点 Web 应用 2 标记为“降级”(2)。 在这种情况下应用程序性能不会受影响，但数据库已暴露，所以如果区域 A 跟着失败时会产生更高的数据丢失风险。
注意
对于灾难恢复，建议将应用程序部署配置限于两个区域。 这是因为大多数 Azure 地理位置仅有两个区域。 如果两个区域同时发生灾难性故障，此配置不会为你的应用程序提供保护。 在此类失败的不可能事件中，可以使用异地还原操作在第三个区域中恢复数据库。 有关详细信息，请参阅 Azure SQL 数据库灾难恢复指南。
中断问题缓解后，辅助数据库会立即自动重新与主数据库同步。 同步期间，主数据库的性能可能受影响。 具体影响取决于新主数据库自故障转移开始后获取的数据量。
注意
缓解服务中断后，流量管理器会开始将连接路由到区域 A 中的应用程序，以用作优先级更高的终结点。 如果打算让主要数据库保留在区域 B 中一段时间，则应该相应地更改流量管理器配置文件中的优先级表。
下图说明了次要区域中的服务中断：
此设计模式的主要 优点 是：
- 将同一 Web 应用程序部署到两个区域中时无需任何特定于区域的配置，也无需使用更多逻辑来管理故障转移。
- 应用程序性能不受故障转移影响，因为 Web 应用程序和数据库始终共存。
区域 B 中的应用程序资源大多时间利用不足，这是需要进行权衡的主要考量。
应用场景 2：可实现业务连续性并提供最高数据保存性能的 Azure 区域
此选项最适合具有以下特征的应用程序：
- 任何数据丢失都具有高业务风险。 如果中断是由灾难性故障引起的，则数据库故障转移只能作为最后考虑的方法。
- 应用程序支持只读和读写操作模式，可在“只读模式”下运行一段时间。
此模式下，读写连接开始出现超时错误时，应用程序会切换到只读模式。 Web 应用程序会部署到这两个区域，并包含一个读写侦听器终结点连接和另一个不同的只读侦听器终结点连接 (1)。 流量管理器配置文件应使用优先级路由。 应为每个区域中的应用程序终结点启用终结点监视 (2)。
下图说明了在发生服务中断之前的此配置：
流量管理器检测到区域 A 的连接故障时，会自动将用户流量切换到区域 B 中的应用程序实例。此模式下，必须将数据丢失宽限期设置为足够大的值，例如 24 小时。 如果在该时间段内解决了中断问题，该措施可确保防止数据丢失。 区域 B 中的 Web 应用程序激活时，读写操作会失败。 此时，应切换到只读模式 (1)。 此模式下，请求会自动路由至辅助数据库。 如果中断是由灾难性故障引起的，则很难在宽限期内缓解故障。 超过宽限期时，故障转移组会触发故障转移。 之后，读写侦听器变为可用状态，其连接恢复正常 (2)。 下图显示恢复过程的两个阶段。
注意
如果在宽限期内解决了主要区域中的中断问题，流量管理器会检测到主要区域的连接恢复，并将用户流量切换回区域 A 中的应用程序实例。如上图所示，此应用程序实例使用区域 A 中的主数据库在读写模式下进行恢复和运行。
如果区域 B 中发生中断，流量管理器检测到区域 B 中的终结点 web-app-2 故障并将其标记为“降级”(1)。 与此同时，故障转移组将只读侦听器切换到区域 A (2)。 此中断不会影响最终用户体验，但是中断期间主数据库会暴露。 下图说明了次要区域中的失败：
解决中断问题后，辅助数据库立即与主数据库同步，只读侦听器切换回区域 B 中的辅助数据库。同步期间，主数据库性能可能略受影响，具体取决于需同步的数据量。
此设计模式具有多个 优点：
- 它在临时服务中断期间可避免数据丢失。
- 停机时间仅取决于流量管理器检测到连接故障的速度，此速度是可配置的。
权衡是应用程序必须能够在只读模式下运行。
业务连续性规划：选择用于云灾难恢复的应用程序设计
特定的云灾难恢复策略可组合或扩展这些设计模式以最好地满足应用程序需求。 如前所述，所选的策略基于要提供给客户的 SLA 和应用程序部署拓扑。 为了帮助用户进行决策，下表基于恢复点目标 (RPO) 和估计的恢复时间 (ERT) 比较了相关选项。
| 模式 | RPO | ERT |
|---|---|---|
| 使用归置的数据库访问权限进行灾难恢复的主动-被动部署 | 读写访问 < 5 秒 | 故障检测时间 + DNS TTL |
| 实现应用程序负载均衡的主动-主动部署 | 读写访问 < 5 秒 | 故障检测时间 + DNS TTL |
| 实现保留数据的主动-被动部署 | 只读访问 < 5 秒 | 只读访问 = 0 |
| 读写访问 = 0 | 读写访问 = 故障检测时间 + 数据丢失宽限期 |