【问题标题】:Amazon Aurora Reader亚马逊极光阅读器
【发布时间】:2020-01-31 15:56:41
【问题描述】:

我有一个包含读取器和写入器实例的 Aurora 集群。阅读器实例的点击率很高,并且时不时地达到 100%。我想知道减少相同负载的可能选项。当前实例类型是 db.r4.4xlarge 。

我还阅读了有关添加多个使用相同端点的读取器实例的信息,AWS 会自动对它们之间的流量进行负载平衡。我很想知道我所要做的是否只是添加另一个阅读器实例并且所有负载平衡都会自动发生?在创建新阅读器时,创建新阅读器会影响集群的性能吗?

如何使用 Redis ElastiCache 实例?如何将它与 RDS 一起使用以减少同一实例的负载?

以上 2 中哪一个是最好的前进方式???请推荐

【问题讨论】:

  • 我还为 Aurora 集群启用了自动缩放,这似乎可以正常工作。也就是说,它在触发时会创建另一个阅读器。但是我是否必须使用“自定义端点”才能有效。因为我可以看到当一个的 CPU 利用率上升时,另一个似乎有点稳定,所以我假设没有发生负载平衡!!?

标签: amazon-web-services amazon-rds amazon-elasticache amazon-aurora


【解决方案1】:

向 Aurora 集群添加更多读取器实例或扩展读取器实例是避免高 CPU 的方法。使用只读端点时,您必须记住几件事

Load Balancing with the Aurora Reader Endpoint

Aurora reader endpoint 包含所有 Aurora 副本,它可以为新连接提供基于 DNS 的循环负载平衡。每次解析读取器端点时,您都​​会获得一个可以连接到的实例 IP,以循环方式选择。

DNS 负载平衡在连接级别(而不是单个查询级别)起作用。您必须在不缓存 DNS 的情况下继续解析端点,以便在每次解析时获得不同的实例 IP。如果您只解析一次端点,然后将连接保留在池中,则对该连接的每个查询都会转到同一个实例。如果您缓存 DNS,则每次解析端点时都会收到相同的实例 IP。

DNS 缓存

由于 DNS 缓存,Aurora 副本可能会遇到不均等的利用率。

除非您使用智能数据库驱动程序,否则您将依赖 DNS 记录更新和 DNS 传播来实现跨 Aurora 副本的故障转移、实例扩展和负载平衡。 目前,Aurora DNS 区域使用 5 秒的短生存时间 (TTL)。确保您的网络和客户端配置不会进一步增加 DNS 缓存 TTL。 请记住,DNS 缓存可以发生在从网络层、操作系统到应用程序容器的任何地方。例如,Java 虚拟机 (JVM) 因无限期缓存 DNS 而臭名昭著,除非另有配置。

Another good read on the same topic.

【讨论】:

  • 您还拥有适用于 Aurora 的自动缩放选项和适用于读取器实例的通用负载均衡器端点。启用自动缩放后,您将必须使用公共读取器端点,以便在多个读取器实例之间平衡负载。
猜你喜欢
  • 2016-12-22
  • 2019-11-30
  • 1970-01-01
  • 2017-12-17
  • 2017-09-15
  • 1970-01-01
  • 1970-01-01
  • 2016-11-26
  • 2012-12-08
相关资源
最近更新 更多