本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon DocumentDB 高可用性和复制
通过使用副本实例，可以在 Amazon DocumentDB（与 MongoDB 兼容）中实现高可用性和读取扩展。单个 Amazon DocumentDB 集群支持单个主实例和最多 15 个副本实例。这些实例可以分布在集群区域的多个可用区中。主实例接受读取和写入流量，而副本实例仅接受读取请求。
集群卷由该集群的多个数据副本组成。不过，集群卷中的数据，对于主实例和数据库集群中的 Amazon DocumentDB 副本表示为单个逻辑卷。副本实例具有最终一致性。它们返回具有最短副本滞后的查询结果 - 通常远远少于主实例写入更新后的 100 毫秒。副本滞后因数据库更改速率而异。也就是说，在对数据库执行大量写入操作期间，您可能发现副本滞后时间变长。
读取扩展
Amazon DocumentDB 副本十分适用于读取扩展，因为它们完全专用于集群卷上的读取操作。写入操作由主实例进行管理。集群卷在集群中的所有实例之间共享。因此，您不必为每个 Amazon DocumentDB 副本复制和维护数据副本。
高可用性
在创建 Amazon DocumentDB 集群时，根据子网组中的可用区数（必须至少为两个），Amazon DocumentDB 将在这些可用区中预置实例。在集群中创建实例时，Amazon DocumentDB 会自动在子网组的可用区中分发实例来平衡集群。此操作还会阻止所有实例位于同一可用区中。
示例
为了说明这一点，请考虑以下示例：创建一个集群，其中包含一个具有三个可用区（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 集群应该与主实例具有相同的实例类，并且位于不同可用区中。
有关更多信息，请参阅下列内容：
全局集群可用性高
为了跨多个 Amazon Web Services 区域 可用性高，您可以设置 Amazon DocumentDB 全局集群。每个全球集群均跨越多个区域，可在跨 Amazon Web Services 区域 中实现低延迟的全局读取以及从停机中进行灾难恢复。Amazon DocumentDB 自动处理从主区域到每个辅助区域的数据复制以及更新。
添加 副本
添加到集群的第一个实例是主实例。在第一个实例之后添加的每一个实例都是副本实例。除主实例之外，每个集群最多可拥有 15 个副本实例。
如果您使用 Amazon Web Services Management Console 创建集群，则同时会自动创建主实例。创建集群和主实例的同时还要创建副本，请选择 Create replica in different zone (在其他区域创建副本)。有关更多信息，请参阅 创建亚马逊文档数据库集群 中的步骤 4.d。要将更多副本添加到 Amazon DocumentDB 集群，请参阅向集群添加 Amazon DocumentDB 实例 。
在使用 Amazon CLI 创建集群时，必须明确地创建主实例和副本实例。有关更多信息，请参阅以下主题的“使用 Amazon CLI”部分：
复制延迟
复制延迟通常为 50 毫秒或更短。副本延迟增长的最常见原因是：
-
主服务器上高写入速率导致只读副本落后于主副本。
-
长时间运行的查询（例如，大型顺序扫描、聚合查询）与传入性写入复制之间的只读副本争用。
-
只读副本上有数目非常庞大的并发查询。
要最大限度减少复制延迟，请尝试以下故障排除技术：
-
如果您的写入速率高或 CPU 使用率较高，我们建议您纵向扩展集群中的实例。
-
如果您的只读副本上有长时间运行的查询，并且对正在查询的文档更新非常频繁，请考虑更改长时间运行的查询，或者针对主/写副本运行这些查询，以避免只读副本争用。
-
如果只读副本上数目非常庞大的并发查询，或者仅只读副本上 CPU 使用率高，则另一种选项是横向扩展只读副本的数目以分散工作负载。
-
由于复制延迟是高写入吞吐量和长时间运行查询的结果，因此我们建议将 dbClusterReplicalagMaximum CW 指标与慢速查询记录器和
WriteThroughput/WriteIOPS指标结合使用，对复制延迟进行故障排除。
通常，我们建议您的所有副本都属于相同实例类型，从而群集失效转移将不导致性能下降。
如果您正在在纵向扩展与横向扩展（例如，六个较小实例与三个较大实例）之间选择，我们通常建议您在扩展之前尝试纵向扩展（较大实例），因为您将获得每个 DB 实例更大的缓冲区缓存。
您应该前瞻性设置复制延迟警报，并将其阈值设置成这样一个值，您认为该值是副本实例上您的数据在它开始影响应用程序的功能之前可以落后（或“过时”）多久的上限。通常，由于工作负载转瞬即逝，我们将建议报警之前复制延迟阈值应被超过几个数据点。
注意
此外，我们建议您为超过 10 秒的复制延迟设置另一个警报。如果您超越这个阈值延续多个数据点，我们建议您纵向扩展您的实例或降低主实例上的写入吞吐量。