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

# Amazon Neptune 数据库集群和实例
<a name="feature-overview-db-clusters"></a>

Amazon Neptune *数据库集群*通过查询管理对数据的访问。集群包括：
+ 一个*主数据库实例*。
+ 最多 15 个*只读副本数据库实例*。

集群中的所有实例共享相同的[底层托管式存储卷](feature-overview-storage.md)，该存储卷专为实现可靠性和高可用性而设计。

您可以通过 [Neptune 端点](feature-overview-endpoints.md)连接到数据库集群中的数据库实例。

## Neptune 数据库集群中的主数据库实例
<a name="feature-overview-primary-instance"></a>

主数据库实例协调针对数据库集群底层存储卷的所有写入操作。它还支持读取操作。

一个 Neptune 数据库集群中只能有一个主数据库实例。如果主实例变得不可用，Neptune 会自动失效转移到其中一个具有您可以指定的优先级的只读副本实例。

## Neptune 数据库集群中的只读副本数据库实例
<a name="feature-overview-read-replicas"></a>

在为数据库集群创建主实例后，您可以在数据库集群中创建最多 15 个只读副本实例，以便为只读查询提供支持。

Neptune 只读副本数据库实例非常适用于扩展读取容量，因为它们完全专用于集群卷上的读取操作。所有写入操作均由主实例进行管理。每个只读副本数据库实例都有自己的端点。

由于集群存储卷由集群中的所有实例共享，因此，所有只读副本实例都会返回相同的查询结果数据，而复制滞后很小。此滞后通常远远少于主实例写入更新后的 100 毫秒，但当写入操作量非常大时，此滞后可能更长一些。

在不同的可用区中提供一个或多个只读副本实例可以提高可用性，因为只读副本充当主实例的失效转移目标。也就是说，如果主实例失败，Neptune 将只读副本实例提升为主实例。当这种情况发生时，在提升的实例重启时会出现短暂的中断，在此期间，对主实例的读写请求将失败，同时引发异常。

相比之下，如果您的数据库集群不包含任何只读副本实例，则当主实例出现故障时，您的数据库集群将保持不可用状态，直到重新创建该实例。与提升只读副本相比，重新创建主实例所需的时间要长得多。

为确保高可用性，我们建议您创建一个或多个只读副本实例，这些实例的数据库实例类与主实例相同，并且与主实例位于不同的可用区。请参阅[Neptune 数据库集群的容错能力](backup-restore-overview-fault-tolerance.md)。

使用控制台，您只需在创建数据库集群时指定多可用区，即可创建多可用区部署。如果数据库集群位于单个可用区中，您可以通过在不同可用区中添加 Neptune 副本来使其成为多可用区数据库集群。

**注意**  
您无法为未加密的 Neptune 数据库集群创建加密的只读副本实例，也无法为加密的 Neptune 数据库集群创建未加密的只读副本实例。

有关如何创建 Neptune 只读副本数据库实例的详细信息，请参阅[使用控制台创建 Neptune 读取器实例](manage-console-create-replica.md)。

## 调整 Neptune 数据库集群中数据库实例的大小
<a name="feature-overview-sizing-instances"></a>

根据 CPU 和内存要求调整 Neptune 数据库集群中实例的大小。实例CPUs 上的 v 数决定了处理传入查询的查询线程的数量。实例上的内存量决定了缓冲区缓存的大小，缓冲区缓存用于存储从底层存储卷提取的数据页的副本。

每个 Neptune 数据库实例的查询线程数等于该实例CPUs 上的 2 x v 数。例如`r5.4xlarge`，具有 16 v 的 a CPUs 有 32 个查询线程，因此可以同时处理 32 个查询。

在所有查询线程都被占用时到达的其它查询将放入服务器端队列，并在查询线程变为可用时以 FIFO 方式进行处理。此服务器端队列可以容纳大约 8000 个待处理请求。装满后，Neptune 会用 `ThrottlingException` 来响应其它请求。您可以使用`MainRequestQueuePendingRequests` CloudWatch 指标监控待处理请求的数量，也可以使用带参数的 [Gremlin 查询状态端点](gremlin-api-status.md)。`includeWaiting`

从客户端的角度来看，查询执行时间除了实际执行查询所花费的时间外，还包括在队列中花费的任何时间。

理想情况下，利用主数据库实例上所有查询线程的持续并发写入负载会显示 90% 或更高的 CPU 利用率，这表明服务器上的所有查询线程都积极参与执行有用的工作。但是，即使在持续并发写入负载下，实际的 CPU 利用率也通常会稍低一些。这通常是因为查询线程正在等待底层存储卷的 I/O 操作完成。Neptune 使用仲裁写入，这种写入在三个可用区中生成六份数据副本，而这六个存储节点中有四个必须确认写入才能被视为持久。当查询线程从存储卷等待此仲裁时，它会被搁置，从而降低 CPU 利用率。

如果您有一个串行写入负载，即您正在执行一个接一个的写入，并等待第一个写入完成后再开始下一个写入，则可以预计 CPU 使用率会更低。确切的数量将是 v CPUs 和查询线程数量的函数（查询线程越多，每次查询的总体 CPU 越少），等待 I/O 会导致一些减少。

有关如何最好地调整数据库实例大小的更多信息，请参阅[为 Amazon Neptune 选择实例类型](instance-types.md)。有关每种实例类型的定价，请参阅 [Neptune 定价页面](https://aws.amazon.com/neptune/pricing/)。

## 在 Neptune 中监控数据库实例性能
<a name="feature-overview-monitoring-instances"></a>

您可以使用 Neptune 中的 CloudWatch 指标来监控数据库实例的性能并跟踪客户端观察到的查询延迟。请参阅[CloudWatch 用于监控 Neptune 中的数据库实例性能](cloudwatch-monitoring-instances.md)。