Amazon Aurora数据库群集无法正确自动平衡

Question

我创建了一个运行MySQL的Amazon Aurora数据库集群，它有三个实例：支持集群的主实例和两个用于平衡的只读副本。 但是，群集似乎根本没有平衡读取。 我有一个副本管理700+选择/秒最大化CPU为99.75％或更高，而另一个副本几乎没有任何CPU使用率为4％，每秒1选择，如果这样。 主要群集实例本身的CPU使用率为33％，因为正在读取副本时正在同时写入它。 复制品之间的滞后时间小于20毫秒。 我的应用程序正在查询群集的只读端点，但似乎没有发生任何平衡。 有没有人知道为什么会发生这种情况或为什么副本处于如此高的CPU使用率？ 无论如何，针对它运行的查询都不复杂。

Answer 1

Aurora群集端点是DNS记录，它们仅在解析期间执行DNS循环。 这意味着当您的客户端应用程序打开与集群端点的连接时，您最终会将端点解析为不同的实例（基本上是不同的IP），通过在多个副本之间划分连接。 过去这一点，没有负载平衡。 连接在实例之间进行条带化，并且在每个连接上运行的查询将转到支持它的相应实例。

现在考虑当您在其后面有一个实例时已经为集群端点创建连接池的情况。 现在，如果添加更多实例，则不会对应用程序产生任何影响，除非您终止连接并重新建立连接。 您将再次执行DNS循环，这次您的一些连接将落在您配置的新实例上。

标注很少：

在Aurora中，您有2个群集端点。 一个（RW）端点始终指向当前写入程序，一个（RO）在您的只读副本之间执行DNS循环。

此外，发生故障转移时，DNS传播可能需要几秒钟，因此在发生故障转移时偶然发生的错误非常自然。

希望这可以帮助。

Answer 2

我的猜测是你没有连接到集群端点。

负载平衡 - 连接到群集端点允许Aurora对数据库群集中的副本进行负载平衡。 这有助于扩展读取工作负载，并可以提高性能，更公平地使用每个副本可用的资源。 如果发生故障转移，如果您连接的副本被提升为主实例，则连接将被删除。 然后，您可以重新连接到阅读器端点，以便将读取的查询发送到群集中的其他副本。

适用于Amazon Aurora的新Reader端点 - 负载平衡和更高可用性

[编辑]

要在单个应用程序中进行负载平衡，您需要重新连接到端点。 如果对所有查询使用相同的连接，则只有一个副本将响应。 但是，打开连接很昂贵，因此除非您的查询需要一些时间才能运行，否则这可能无法提供太多好处。

Answer 3

我们已经实现了一个驱动程序来尝试缓解这个问题，并获得了一些明显的收益： https ： //github.com/DiceTechnology/dice-fairlink

它会定期发现读取副本以赶上群集更改和它们之间的循环连接。

尽管没有测量任何CPU利用率，但我们观察到的负载分布比集群读取器端点的基于本机DNS的循环更好

Answer 4

Aurora基于DNS的负载均衡在连接级别（而不是单个查询级别）工作。 您必须保持解析端点而不缓存DNS以在每个分辨率上获得不同的实例IP。 如果您只解析端点一次，然后在池中保持连接，则该连接上的每个查询都会转到同一个实例。 如果缓存DNS，则每次解析端点时都会收到相同的实例IP。

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