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

New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability

[编辑]

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

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 documentation和Aurora whitepaper。