Share via

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Cosmos DB for NoSQL 中的高可用性（可靠性）

  • 项目

本文介绍 Azure CosmosDB for NoSQL 中的高可用性（可靠性）支持，包括可用性区域以及跨区域灾难恢复和业务连续性。

有关 Azure Cosmos DB for NoSQL 的一般复原建议，请参阅 Azure Cosmos DB for NoSQL 的复原建议。

可用性区域支持

Azure 可用性区域是每个 Azure 地区内的至少三个在物理上独立的数据中心组。 每个区域中的数据中心都配备了独立的电源、冷却系统和网络基础结构。 在本地区域发生故障的情况下，设计可用性区域，以便一个区域受到影响时，其余两个区域支持区域服务、容量和高可用性。

故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。 容错是通过 Azure 服务的冗余和逻辑隔离来实现的。 有关 Azure 中可用性区域的详细信息，请参阅地区和可用性区域。

已启用 Azure 可用性区域的服务旨在提供适当级别的可靠性和灵活性。 可以通过两种方式进行相关配置。 可以采用区域冗余配置，实现跨区域自动复制，也可以采用区域性配置，将实例固定到特定区域。 还可以将这些方法结合。 有关区域式与区域冗余体系结构的详细信息，请参阅有关使用可用性区域和地区的建议。

Azure Cosmos DB 是一项多租户服务，可透明地管理各个计算节点的所有详细信息。 无需考虑任何类型的修补或计划内维护。 Azure Cosmos DB 通过系统执行的所有自动维护操作来保证 可用性的 SLA 和 P99 延迟。

Azure Cosmos DB 提供：

单个节点中断后的复原能力。 Azure Cosmos DB 保证四个副本仲裁内的帐户的每个 Azure 区域中至少有三个数据副本，从而自动缓解副本中断。 对于单个节点中断，此保证会使 RTO 为 0，RPO 为 0，无需更改或配置应用程序。

区域中断复原能力。 使用可用性区域部署 Azure Cosmos DB 帐户时，Azure Cosmos DB 会提供 RTO (0)和 RPO (0)，即使在区域中断的情况下也是如此。 有关 RTO 的信息，请参阅恢复目标。

启用可用性区域后，Azure Cosmos DB for NoSQL 支持区域冗余配置。

先决条件

  • 副本必须部署在支持可用性区域的 Azure 区域中。 若要查看你所在的区域是否支持可用性区域，请参阅支持的区域列表。

  • 在使用可用性区域的影响中确定可用性区域是否为当前配置增加了足够的价值。

使用可用性区域的影响

可用性区域对 Cosmos DB for NoSQL 数据库高可用性的影响取决于帐户的一致性级别以及哪些区域支持可用性区域。 在许多情况下，如果帐户是多区域的，则可用性区域不会增加价值或者只会增加极小的价值（除非配置了强一致性）。

请参阅下表来评估在当前帐户配置中使用可用性区域的影响：

帐户一致性级别 支持可用性区域的区域 使用可用性区域的影响
异步（有限过期或更弱） 任意数量的次要读取区域。 提供极小的价值，因为 SDK 已在读取区域失败时提供无缝的读取重定向。
同步（强） 两个或更多个次要读取区域 提供边际价值，因为如果读取区域失去可用性，系统可以利用动态仲裁，从而允许继续写入。
同步（强） 一个次要读取区域 提供更大的价值，因为在这种情况下读取区域的丢失可能会影响写入可用性。
全部 写入区域和任意数量的次要区域 确保针对区域故障的写入操作具有更高的可用性。
全部 单区域 单个区域无法从多区域故障转移功能中受益。 使用可用性区域可以防止由于区域故障而造成的总体可用性损失。

SLA 改进

由于可用性区域在物理上是独立的，并且提供不同的电源、网络和散热资源，因此可用性 SLA（服务级别协议）(99.995%) 高于使用单个区域的帐户 (99.99%)。 支持可用性区域的区域按 25% 收取溢价，不支持可用性区域的区域则不收取溢价。 此外，对于配置了多区域写入的帐户和/或配置了自动缩放模式的集合，可以免除可用性区域的溢价。

向 Cosmos DB 帐户添加更多区域通常会使现有计费增加 100%（加法而不是乘法），尽管各区域之间的成本存在微小差异。 有关详细信息，请参阅定价页。

启用可用性区域、添加其他区域或打开多区域写入可以被视为一种分层方法，可以在每一步中提高给定 Cosmos DB 帐户的复原能力和可用性 - 从没有可用性区域配置的单个区域的 4 个 9 可用性，到具有可用性区域的单个区域的 4 个半 9 可用性，一直到启用了多区域写入选项的多区域配置的 5 个 9 可用性。 请参阅下表了解每种配置的 SLA 摘要。

KPI 无可用性区域的单区域写入 有可用性区域的单区域写入 有或无可用性区域的多区域、单区域写入 有可用性区域的多区域、单区域写入 有或无可用性区域的多区域、多区域写入
写入可用性 SLA 99.99% 99.995% 99.99% 99.995% 99.999%
读取可用性 SLA 99.99% 99.995% 99.999% 99.999% 99.999%
区域故障：数据丢失 数据丢失 无数据丢失 无数据丢失 无数据丢失 无数据丢失
区域故障：可用性 可用性缺失 无可用性缺失 无可用性缺失 无可用性缺失 无可用性缺失
区域中断：数据丢失 数据丢失 数据丢失 取决于一致性级别。 有关详细信息，请参阅一致性、可用性和性能权衡。 取决于一致性级别。 有关详细信息，请参阅一致性、可用性和性能权衡。 取决于一致性级别。 有关详细信息，请参阅一致性、可用性和性能权衡。
区域中断：可用性 可用性缺失 可用性缺失 读取区域故障没有可用性缺失，写入区域故障有暂时缺失 读取区域故障没有可用性缺失，写入区域故障有暂时缺失 受影响区域内无读取可用性损失、临时写入可用性损失
价格 (1) 不适用 预配 RU/秒 x 1.25 速率 预配的 RU/秒 x N 个区域 预配的 RU/秒 x 1.25 速率 x N 个区域（2） 多区域写入速率 x N 个区域

1 对于无服务器帐户，RU 乘以系数 1.25。

2 1.25 速率仅适用于启用可用性区域的区域。

创建启用可用性区域的资源

只有在将新区域添加到 Azure Cosmos DB NoSQL 帐户时，才可以配置可用性区域。

若要启用可用性区域支持，可以使用：

迁移到可用性区域支持

若要了解如何将 Cosmos DB 帐户迁移到可用性区域支持，请参阅将 Azure Cosmos DB for NoSQL 迁移到可用性区域支持。

跨区域灾难恢复和业务连续性

灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件（例如自然灾害或部署失败）中恢复。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前，请参阅设计灾难恢复策略的建议。

在 DR 方面，Microsoft 使用责任共担模型。 在共担责任模型中，Microsoft 会确保基线基础结构和平台服务可用。 同时，许多 Azure 服务不会自动复制数据，也不会从失败区域回退以交叉复制到另一个启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导，你可以使用特定于服务的功能来支持快速恢复，从而帮助制定 DR 计划。

区域中断 指的是跨所有可用性区域影响 Azure 区域中所有 Azure Cosmos DB 节点的中断。 对于极少数区域中断的情况，可以将 Azure Cosmos DB 配置为支持持续性和可用性的各种结果。

持续性

当在单个区域中部署 Azure Cosmos DB 帐户时，通常不会发生数据丢失。 在受影响的区域中恢复 Azure Cosmos DB 服务后，会还原数据访问。 只有在 Azure Cosmos DB 区域发生不可恢复的灾难时，才可能发生数据丢失。

为了帮助防止区域中的毁灭性灾难可能导致数据完全丢失，Azure Cosmos DB 提供了两种备份模式：

  • 连续备份 每 100 秒备份一次每个区域。 它们使你能够以 1 秒的粒度将数据还原到任何时间点。 在每个区域，备份取决于该区域提交的数据。 如果该区域已启用可用性区域，则备份将存储在区域冗余的存储帐户中。
  • 定期备份，从帐户下的所有容器完全备份所有分区，不跨分区同步。 最小备份间隔为 1 小时。

在多个区域中部署 Azure Cosmos DB 帐户时，数据持续性取决于在该帐户上配置的一致性级别。 对于所有一致性级别，下表详细说明了在至少两个区域中部署的 Azure Cosmos DB 帐户的 RPO。

一致性级别 区域中断的 RPO
会话一致性、一致性前缀或最终一致性 少于 15 分钟
有限过期性 K 和 T
强 0

K = 某项的版本（即更新）数。

T = 自上次更新以来的时间间隔。

对于多区域帐户，K 和 T 的最小值为 100,000 次写入操作或 300 秒。 此值定义了使用有限过期时数据的最小 RPO。

有关一致性级别之间差异的详细信息，请参阅 Azure Cosmos DB 中的一致性级别。

服务托管的故障转移

如果解决方案需要在区域中断期间保持持续运行，可以将 Azure Cosmos DB 配置为跨多个区域复制数据，并在需要时透明地故障转移到正常工作的区域。

发生区域性服务中断时，单区域帐户的可访问性可能会丢失。 要确保始终保持业务连续性，建议设置具有单写入区域和至少第二个（读取）区域的 Azure Cosmos DB 帐户并启用服务托管的故障转移。

服务托管故障转移允许 Azure Cosmos DB 对多区域帐户的写入区域进行故障转移，从而以数据丢失为代价来保持业务连续性，如前面的持久性部分所述。 区域故障转移在 Azure Cosmos DB 客户端中进行检测和处理。 它们不需要在应用程序中进行任何更改。 有关如何启用多个读取区域和服务托管故障转移的说明，请参阅 使用 Azure 门户管理 Azure Cosmos DB 帐户。

重要

如果选择了具有多个读取区域的单区域写入配置，强烈建议配置用于生产工作负载的 Azure Cosmos DB 帐户，以启用服务管理的故障转移。 此配置支持 Azure Cosmos DB 将帐户数据库故障转移到可用区域。 如果没有此配置，则在写入区域服务中断的整个持续时间内，帐户会遇到写入可用性损失的情况。 由于缺少区域连接，手动故障转移不会成功。

警告

即使启用了服务管理的故障转移，部分服务中断也可能需要 Azure Cosmos DB 服务团队进行手动干预。 在这些情况下，故障转移可能需要长达 1 小时（或更长时间）才能生效。 为了在部分服务中断期间提高写入可用性，除了服务管理的故障转移之外，我们还建议启用可用性区域。

多个写入区域

可以将 Azure Cosmos DB 配置为接受多个区域内的写入。 此配置有助于减少地理分散式应用程序中的写入延迟。

为多个写入区域配置 Azure Cosmos DB 帐户时，不支持强一致性，可能会出现写入冲突。 有关如何解决这些冲突的详细信息，请参阅 使用多个写入区域时的冲突类型和解决策略。

重要

频繁更新同一个文档 ID（或在 TTL 或删除后频繁重新创建同一文档 ID）会对复制性能产生影响，因为系统中生成的冲突数量会增加。  

冲突解决区域

当 Azure Cosmos DB 帐户配置了多区域写入时，其中一个区域将充当写入冲突中的仲裁者。

多区域写入的最佳做法

下面是写入多个区域时要考虑的一些最佳做法。

将本地流量保留在本地

使用多区域写入时，应用程序应严格向本地 Cosmos DB 区域发出源自本地区域的读写流量。 为了获得最佳性能，请避免跨区域调用。

应用程序必须避免以下反模式以最大程度地减少冲突：

  • 将相同的写入操作发送到所有区域，从而提高获得快速响应时间的几率

  • 根据每个请求随机确定读取或写入操作的目标区域

  • 使用轮循机制策略根据每个请求确定读取或写入操作的目标区域。

避免依赖复制延迟

无法为强一致性配置多区域写入帐户。 在 Azure Cosmos DB 在本地复制数据后，写入的区域会立即响应，同时以异步方式全局复制数据。

虽然不常见，但在异地复制数据时，一个或几个分区上可能会发生复制延迟。 复制延迟可能是由于网络流量中的罕见波动或冲突解决率高于平常导致。

例如，应用程序写入区域 A 但从区域 B 读取的体系结构引入了对两个区域之间复制延迟的依赖。 但是，如果应用程序读取和写入同一区域，即使存在复制延迟，性能也会保持不变。

评估写入操作的会话一致性使用情况

在会话一致性中，使用会话令牌执行读写操作。

对于读取操作，Azure Cosmos DB 会将缓存的会话令牌发送到服务器，保证接收与指定（或较新）会话令牌相对应的数据。

对于写入操作，Azure Cosmos DB 会将会话令牌发送到数据库，保证只在服务器已赶上提供的会话令牌时保留数据。 在单区域写入帐户中，始终保证写入区域已赶上会话令牌。 但是，在多区域写入帐户中，写入的区域可能没有赶上向另一个区域发出的写入。 如果客户端使用来自区域 B 的会话令牌写入区域 A，在赶上区域 B 中所做的更改之前，区域 A 将无法保留数据。

在客户端实例之间传递会话令牌时，最好仅将会话令牌用于读取操作而非写入操作。

缓解对同一文档的快速更新

当重复更新同一文档时，服务器用于解决或确认不存在冲突的更新可能会与应用程序触发的写入发生冲突。 在解决冲突期间，对同一文档的连续快速重复更新会导致更高的延迟。

虽然重复更新同一文档中的偶尔突发不可避免，但如果稳定状态流量在较长时间内看到对同一文档的快速更新，可以考虑改为探索新建文档的体系结构。

读取和写入中断

在服务还原之前，单区域帐户的客户端会遇到读写可用性损失的情况。

多区域帐户会经历不同的行为，具体取决于以下配置和中断类型。

配置 中断 可用性影响 持续性影响 要执行的操作
单个写入区域 读取区域中断 所有客户端都会自动将读取重定向到其他区域。 对于所有配置，读取或写入可用性不会损失。 例外是配置两个具有强一致性的区域，在还原服务之前，这些区域的写入可用性会损失。 或者，如果启用服务托管故障转移，服务会将区域标记为失败，并发生故障转移。 无数据丢失。 在中断期间，请确保剩余区域中预配了足够的请求单位(RU)以支持读取流量。

当中断结束时，请根据需要重新调整预配的 RU。
单个写入区域 写入区域中断 客户端会将读取重定向到其他区域。

如果未启用服务托管故障转移，客户端会遇到写入可用性损失的情况。 中断结束时，会自动还原写入可用性。

如果启用了服务托管故障转移，在服务将故障转移管理到选择的新写入区域之前，客户端会遇到写入可用性损失的情况。		 如果未选择强一致性级别，服务可能不会将一些数据复制到剩余的活动区域。 此复制取决于所选的 一致性级别。 如果受影响的区域遭受永久性数据丢失，你可能会丢失未复制的数据。 在中断过程中，请确保剩余区域中预配了足够的 RU 以支持读取流量。

不要 在中断期间触发手动故障转移，因为它不会成功。

当中断结束时，请根据需要重新调整预配的 RU。 使用适用于 NoSQL 的 API 的帐户也可能从 冲突源 恢复失败区域中的未复制数据。
多个写入区域 任何区域中断 写入可用性可能会暂时损失，这类似于启用了服务托管故障转移的单写入区域。 如果中断时发生大量冲突写入，冲突解决区域 的故障转移还可能导致写入可用性损失。 失败区域中最近更新的数据可能在剩余的活跃区域中不可用，具体取决于所选的 一致性级别。 如果受影响的区域遭受永久性数据丢失，可能会丢失未复制的数据。 在中断过程中，请确保剩余区域中预配了足够的 RU 以支持更多流量。

中断结束时，可以根据需要重新调整预配的 RU。 如果可能，Azure Cosmos DB 会自动恢复失败区域中的非复制数据。 此自动恢复使用为使用适用于 NoSQL 的 API 的帐户配置的冲突解决方法。 对于使用其他 API 的帐户，此自动恢复使用 最后写入胜出。

有关读取区域中断的其他信息

  • 断开受影响区域的连接，并将其标记为脱机。 Azure Cosmos DB SDK 会将读取调用重定向到首选区域列表中的下一个可用区域。

  • 如果首选区域列表中无可用区域，调用会自动回退到当前的写入区域。

  • 处理读取区域服务中断不需要对应用程序代码进行更改。 受影响的读取区域重新联机后，它会自动与当前写入区域同步，并在完全回复后再次可用于处理读取请求。

  • 后续的读取会重定向到恢复的区域，不需更改应用程序代码。 在故障转移和重新加入上一个失败的区域期间，Azure Cosmos DB 会继续遵循读取一致性保证。

  • 即使在发生了 Azure 区域永久无法恢复的罕见不幸事件中，如果为多区域 Azure Cosmos DB 帐户配置了强一致性，也不会丢失数据。 多区域 Azure Cosmos DB 帐户具有前面 持续性部分指定的持续性特征。

有关写入区域中断的其他信息

  • 在写入区域中断期间，如果在 Azure Cosmos DB 帐户上配置了服务托管故障转移，则 Azure Cosmos DB 帐户会将次要区域提升为新的主要写入区域。 会按你指定的区域优先级顺序故障转移到其他区域。

  • 不应触发手动故障转移，这在存在源或目标区域中断时不会成功。 原因是故障转移过程包括一致性检查，要求在区域之间建立连接。

  • 当上一个受影响的区域重新联机时，可以通过 冲突源 使用该区域失败时未复制的任何写入数据。 应用程序可以读取冲突源，根据特定于应用程序的逻辑解决冲突，并根据需要将更新后的数据写回 Azure Cosmos DB 容器。

  • 在之前受影响的写入区域恢复后，它会在 Azure 门户中显示为“联机”，可用作读取区域。 目前，可以使用 [PowerShell、Azure CLI 或 Azure 门户](../cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account 安全地切换回作为写入区域的恢复区域。 在切换写入区域之前、期间或之后，数据或可用性都不会丢失。 应用程序仍然高度可用。

警告

如果写入区域出现故障，而 Azure Cosmos DB 帐户通过服务托管的故障转移将次要区域提升为新的主要写入区域，那么原始写入区域将不会在恢复后自动回升为写入区域。 你有责任使用 PowerShell、Azure CLI 或 Azure 门户切回恢复的区域作为写入区域（在安全的情况下，如上所述）。

服务中断检测、通知和管理

对于单区域帐户，在 Azure Cosmos DB 区域中断期间，客户端会遇到读写可用性损失的情况。 多区域帐户会经历不同的行为，如下表所述。

写入区域 服务托管故障转移 期望 要执行的操作
单个写入区域 未启用 如果在未使用强一致性时读取区域内发生中断，所有客户端会重定向到其他区域。 读取或写入可用性不会损失，数据也不会丢失。 使用强一致性时，如果剩余的读取区域少于两个，则读取区域中断可能会影响写入可用性。

如果写入区域发生中断，客户端会遇到写入可用性损失的情况。 如果未选择强一致性，服务可能不会将一些数据复制到剩余的活动区域。 此复制取决于所选的 一致性级别。 如果受影响的区域遭受永久性数据丢失，可能会丢失未复制的数据。

当中断结束时，Azure Cosmos DB 将自还原写入可用性。		 在中断过程中，请确保剩余区域中预配了足够的 RU 以支持读取流量。

不要 在中断期间触发手动故障转移，因为它不会成功。

当中断结束时，请根据需要重新调整预配的 RU。
单个写入区域 已启用 如果在未使用强一致性时读取区域内发生中断，所有客户端会重定向到其他区域。 读取或写入可用性不会损失，数据也不会丢失。 使用强一致性时，如果剩余的读取区域少于两个，读取区域中断可能会影响写入可用性。

如果写入区域发生中断，则在 Azure Cosmos DB 根据你的首选项选择新的区域作为新写入区域前，客户端会遇到写入可用性损失的情况。 如果未选择强一致性，服务可能不会将一些数据复制到剩余的活动区域。 此复制取决于所选的 一致性级别。 如果受影响的区域遭受永久性数据丢失，可能会丢失未复制的数据。		 在中断过程中，请确保剩余区域中预配了足够的 RU 以支持读取流量。

不要 在中断期间触发手动故障转移，因为它不会成功。

中断结束时，可以将写入区域移回原始区域，并根据需要重新调整预配的 RU。 使用适用于 NoSQL 的 API 的帐户也可能从 冲突源 恢复失败区域中的未复制数据。
多个写入区域 不适用 失败区域中最近更新的数据可能在剩余的活跃区域中不可用。 最终一致性、一致性前缀和会话一致性级别可保证过期时间少于 15 分钟。 根据配置的不同，有限过期可保证更新次数少于 K或时间少于 T 秒。 如果受影响的区域遭受永久性数据丢失，可能会丢失未复制的数据。 在中断过程中，请确保剩余区域中预配了足够的 RU 以支持更多流量。

中断结束时，可以根据需要重新调整预配的 RU。 如果可能，Azure Cosmos DB 会恢复失败区域中的未复制数据。 此自动恢复使用为使用适用于 NoSQL 的 API 的帐户配置的冲突解决方法。 对于使用其他 API 的帐户，此恢复使用最后写入有效。

高可用性测试

即使 Azure Cosmos DB 帐户高度可用，应用程序也不一定能够正常保持高可用性。 要测试应用程序的端到端高可用性，请在应用程序测试或灾难恢复(DR)演练过程中，暂时禁用帐户的服务托管故障转移。 使用 PowerShell、Azure CLI 或 Azure 门户调用手动故障转移，然后监视应用程序。 完成测试后，可以故障回复到主要区域，并还原该帐户的服务托管故障转移。

重要

在源或目标区域发生 Azure Cosmos DB 中断期间，不要调用手动故障转移。 手动故障转移需要区域连接才能保持数据一致性，因此不会成功。

相关内容