Amazon DocumentDB 高可用性和复制 - Amazon DocumentDB
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Amazon DocumentDB 高可用性和复制

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

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

读取扩展

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

高可用性

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

Example

要说明该点,请考虑创建一个具有三个可用性区域子网组的群集的示例: AZ1AZ2,和 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秒的复制拖布设置另一个警报。如果您超过了多个数据点的阈值,建议您扩展实例或减少主实例上的写吞吐量。