Amazon DocumentDB 高可用性和复制

通过使用副本实例，可以在 Amazon DocumentDB（与 MongoDB 兼容）中实现高可用性和读取扩展。单一 Amazon DocumentDB 群集支持单个主实例和 15 复制副本实例。这些实例可以分布在集群区域的多个可用区中。主实例接受读取和写入流量，而副本实例仅接受读取请求。

集群卷由该集群的多个数据副本组成。而集群卷中的数据被表示为集群中的主实例和 Amazon DocumentDB 副本的单个逻辑卷。副本实例具有最终一致性。它们返回具有最短副本滞后的查询结果 - 通常远远少于主实例写入更新后的 100 毫秒。副本滞后因数据库更改速率而异。也就是说，在对数据库执行大量写入操作期间，您可能发现副本滞后时间变长。

读取扩展

Amazon DocumentDB 副本十分适用于读取扩展，因为它们完全专用于集群卷上的读取操作。写入操作由主实例进行管理。集群卷在集群中的所有实例之间共享。因此，您不必为 Amazon DocumentDB 副本复制和维护数据副本。

高可用性

当您创建 Amazon DocumentDB 群集，取决于子网组中的可用性分区数量（必须至少有两个）， Amazon DocumentDB 在可用区域中规定实例。在集群中创建实例时，Amazon DocumentDB 会自动在子网组的可用区中分发实例来平衡集群。此操作还会阻止所有实例位于同一可用区中。

Example

要说明该点，请考虑创建一个具有三个可用性区域子网组的群集的示例: AZ1， AZ2，和 AZ3.

在创建集群中的第一个实例时，它是主实例并位于其中的一个可用区中。在本示例中，它是 AZ1. 创建的第二个实例是复制副本实例，位于其他两个可用性区之一，说 AZ2. 创建的第三个实例是复制副本实例，位于其余可用性区域， AZ3. 如果创建更多的实例，它们将分布在多个可用区中，以便在集群中实现平衡。

如果在主实例 (AZ1) 中发生故障，则会触发故障转移，并将其中的一个现有副本提升为主实例。在旧的主实例恢复时，它将变为预置它的同一可用区 (AZ1) 中的副本。当您调配三实例群集时， Amazon DocumentDB 继续保留该三实例群集。 Amazon DocumentDB 自动处理实例故障的检测、故障切换和恢复，而无需任何手动干预。

在 Amazon DocumentDB 执行故障转移并恢复实例时，恢复的实例保留在最初预置它的可用区中。但是，此实例的角色可能从主实例变为副本。这样做是为了防止出现以下情况：一系列故障转移可能导致所有实例位于同一可用区中。

您可以将 Amazon DocumentDB 副本指定为故障转移目标。即，如果主实例发生故障，指定的 Amazon DocumentDB 副本或某个层中的副本将提升为主实例。提升过程只造成短暂的中断，在此期间，对主实例发出的读写请求将失败，并且会出现异常。如果您的 Amazon DocumentDB 群集不包括任何 Amazon DocumentDB 复制副本当主实例失败时，将重新创建。提升 Amazon DocumentDB 副本要比重新创建主实例快得多。

对于高可用性场景，建议您创建一个或多个 Amazon DocumentDB 副本。您的 Amazon DocumentDB 集群应该与主实例具有相同的实例类，并且位于不同可用区中。

有关更多信息，请参阅以下内容：。

添加副本

添加到集群的第一个实例是主实例。在第一个实例之后添加的每一个实例都是副本实例。除主实例之外，每个集群最多可拥有 15 个副本实例。

如果您使用 AWS 管理控制台 创建集群，则同时会自动创建主实例。要在创建群集和主实例时同时创建复制副本，请选择 在不同区域创建复制副本. 有关更多信息，请参阅 中的步骤 4.d。创建 Amazon DocumentDB集群. 要将更多副本添加到 Amazon DocumentDB 集群，请参阅。将 Amazon DocumentDB 实例添加到集群.

在使用 AWS CLI 创建集群时，必须明确地创建主实例和副本实例。有关更多信息，请参阅以下主题的“使用 AWS CLI”部分：

复制延迟

复制延迟通常为50ms或更低。复制副本延迟增加的最常见原因是:

  • 主要的写入速率会导致读取复制副本落后于主。

  • 长期运行查询（例如，大序列扫描、聚合查询）和传入写入复制之间读取复制副本的争用。

  • 读取副本上的并发查询数量很多。

要最大程度地减少复制差异，请尝试以下故障排除技术:

  • 如果您的写入速率高或高CPU利用率，建议您在群集中扩展实例。

  • 如果读取副本上有长时间的运行查询，并且对正在查询的文档非常频繁的更新，请考虑更改您的长期运行查询，或者将它们与主/写复制副本进行对比，以避免读取副本上的争用。

  • 如果读取副本中只有很大数量的并发查询或高的CPU利用率，则另一个选项是扩展读取副本数量以扩展工作负载。

  • 由于复制延迟是高写入吞吐量和长时间运行查询的结果，我们建议使用DBClusterReplicalagmaximumCW度量与缓慢查询记录器和 WriteThroughput/WriteIOPS 度量。

一般来说，我们建议所有复制副本都是相同的实例类型，以便群集故障切换不会导致性能降级。

如果您在扩展和缩小（例如6个较小的实例与三个较大的实例）之间进行选择，我们通常建议在扩展前尝试扩展第一个（更大的实例），因为您将获得每个数据库实例的更大缓冲缓存。

主动设置复制延迟警报，并将其阈值设置为一个值的值，即您认为自己的数据在复制副本实例的后面有多远（或“Stale”），在它开始影响应用程序功能之前。一般来说，我们会建议在报警之前由于瞬态工作负载而超出复制延迟阈值。

注意

此外，我们建议您为超过10秒的复制拖布设置另一个警报。如果您超过了多个数据点的阈值，建议您扩展实例或减少主实例上的写吞吐量。