Amazon Neptune 数据库集群和实例 - Amazon Neptune
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

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

Amazon Neptune 数据库集群和实例

Amazon Neptune数据库群集通过查询管理对数据的访问。集群包含以下内容:

  • One主数据库实例。.

  • 最多 15 个只读副本数据库实例。.

集群中的所有实例都共享相同。底层托管存储卷,旨在实现可靠性和高可用性。

通过以下方式连接到数据库集群中的数据库实例Neptune 终端.

Neptune 数据库集群中的主数据库实例

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

Neptune 数据库集群中只能有一个主数据库实例。如果主实例变得不可用,Neptune 会自动故障切换到具有您可以指定的优先级的只读副本实例之一。

Neptune 数据库集群中的只读副本数据库实例

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

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

由于群集存储卷在群集中的所有实例之间共享,因此所有只读副本实例都返回相同的数据以获取查询结果,而复制延迟很小。此滞后通常远少于主实例写入更新后的 100 毫秒,但如果写入操作量非常大,则会稍长一些。

在不同的可用区中拥有一个或多个只读副本实例可以提高可用性,因为只读副本作为主实例的故障转移目标。也就是说,如果主实例失败,Neptune 将提升只读副本实例为主实例。发生这种情况时,升级的实例会出现短暂的中断,在此期间,对主实例发出的读写请求将失败,但会出现异常。

相比之下,如果数据库集群不包含任何只读副本实例,则在主实例出现故障时,您的数据库集群仍然不可用,直到重新创建。重新创建主实例比提升只读副本花费的时间要长得多。

为确保高可用性,我们建议您创建一个或多个只读副本实例,这些实例与主实例具有相同的数据库实例类别,且位于与主实例不同的可用区中。请参阅Neptune 数据库集群的容错能力

跨可用区创建只读副本时,Neptune 会自动预置并同步维护副本。主数据库实例将跨可用区同步复制到只读副本,以提供数据冗余、消除 I/O 冻结并在系统备份期间将延迟峰值降至最小。在计划内的系统维护期间,运行高性能的数据库实例可以提高可用性,并帮助保护数据库以防发生故障和可用区中断。

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

注意

您无法为未加密的 Neptune 数据库集群创建加密的只读副本实例,也不能为加密的 Neptune 数据库集群创建未加密的只读副本实例。

有关如何创建 Neptune 只读副本数据库实例的详细信息,请参阅。使用控制台创建 Neptune 副本.

调整 Neptune 数据库集群中的数据库实例的

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

每个 Neptune 数据库实例都有一些查询线程数量等于该实例上的 2 x vCPUs 数。网络 ACL 和安全组都允许 (因此可到达您的实例) 的发起 ping 的r4.xlarge例如,对于 2 个 vCPUs,有 4 个查询线程,因此可以同时处理 4 个请求。网络 ACL 和安全组都允许 (因此可到达您的实例) 的发起 ping 的r5.4xlarge,具有 16 个 vCPUs,有 32 个查询线程,因此可以同时处理 32 个查询。

占用所有查询线程时到达的其他查询将放入服务器端队列中,并在查询线程可用时以 FIFO 的方式进行处理。此服务器端队列可以容纳大约 8000 个待处理的请求。一旦已满,Neptune 会用ThrottlingException. 您可以使用MainRequestQueuePendingRequestsCloudWatch 指标,或者使用Gremlin 查询状态终端节点使用includeWaiting参数。

从客户端角度来看,查询执行时间包括在队列中花费的任何时间,以及实际执行查询所花费的时间。

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

如果您的串行写入负载正在执行一个接一个写入并等待第一个写入完成后再开始下一次写入操作,则可以预计 CPU 利用率仍会降低。确切的数量将取决于 vCPUs 和查询线程的数量(查询线程越多,每个查询的总体 CPU 越少),而等待 I/O 会导致一些减少。

监控 Neptune 中的数据库实例性能

您可以使用 Neptune 中的 CloudWatch 指标来监控数据库实例的性能,并跟踪客户端观察到的查询延迟。请参阅使用 CloudWatch 监控 Neptune 中的数据库实例性能