Aurora自动缩放的实例中没有发生相等的连接分配

Question

我们正在使用AWS Aurora作为数据库运行基于REST API的春季启动应用程序。我们的应用程序连接到只读的Aurora MySQL RDS实例。我们正在对其进行负载测试。最初，我们只有一个数据库，并且具有自动缩放功能，这是在CPU较高的情况下触发的。现在，我们期望如果通过一个数据库实例获得一些X吞吐量，那么在自动缩放发生时，我们应该获得大约1.8倍的吞吐量，并且连接应该与新创建的数据库实例平均分配。但这没有发生，相反，两个数据库实例上的数据库连接都不稳定。因此，我们的负载无法平均分配，并且无法获得理想的吞吐量。有时一个数据库正在100％CPU上运行，而另一个数据库仍在20％CPU上运行，几分钟后将其反转。

Driver - com.mysql.jdbc.driver
Maximum active connections=100
Max age = 300000
Initial pool size = 10

Tomcat jdbc池用于连接池

注意：1）我们还禁用了jvm网络DNS缓存。2）我们还尝试每5分钟刷新一次数据库连接，即使活动的连接也是如此。3）我们尝试了AWS提出的所有建议，但没有任何效果。4）我们甚至编写了一个lambda代码来在出现新的数据库实例时更新Route 53，以避免集群端点缓存，但仍然存在相同的问题。任何人都可以请帮忙的最佳实践是什么，因为目前我们还不能将其投入生产。

Answer 1

这不是一个很好的答案，但由于您还没有收到任何回复，因此我有一些想法。

\n\n

1) 您看到的行为复制了负载均衡器的错误路由逻辑
\n这并不奇怪，但这在小型 Web 服务器部署 \xe2\x80\x93 尤其是长时间运行的查询中更为常见。通过连接池，您可以反映这种情况。

\n\n

2）按照这个假设，我们需要猜测亚马逊如何选择平衡只读副本的流量。
\n即使在他们的白皮书中，他们也没有提到他们是如何进行路由的：https://www.allthingsdistributed.com/files/p1041-verbitski.pdf

\n\n

可能的选项是route53 或NLB。\n我最好的猜测是他们正在使用NLB。NLB 直到 2017 年第三季度才对我们可用，Aurora 是两年前的，但这仍然是一个合理的猜测。\nNLB 可以让我们基于最少连接进行平衡（比循环法好得多）。

\n\n

3）验证假设
\n如果使用了route53，那么我们就可以使用DNS来找出答案。\n我对route53端点进行了挖掘，发现它给了我一个答案

\n\n

dig +nocmd +noall +answer zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com\nzzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com. 1 IN CNAME zzz-0.yyy.us-east-1.rds.amazonaws.com.\nzzz-0.yyy.us-east-1.rds.amazonaws.com. 5 IN A 10.32.8.33\n

\n\n

我又做了一次，得到了不同的答案。

\n\n

dig +nocmd +noall +answer zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com\nzzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com. 1 IN CNAME zzz-2.yyy.us-east-1.rds.amazonaws.com.\nzzz-2.yyy.us-east-1.rds.amazonaws.com. 5 IN A 10.32.7.97\n

\n\n

您可以看到只读端点向我提供了 CNAME 结果

\n\n

Zzz 是我的集群的名称，yyy 来自我的 cloudformation 堆栈结构，yyy 来自亚马逊。

\n\n

注意：zzz-0 和 zzz-2 是两个只读副本。

\n\n

我们在这里可以看到，我们有用于负载均衡的route53。

\n\n

4) Route53 负载平衡
\n他们可能在所有健康的只读副本上设置循环法的 Route53。
\nTTL 可能是 5 秒。\n健康的节点将被删除，但没有基于

\n\n

5) 后果
\nA) 使用只读端点只能平衡不健康实例的流量
\nB) 数据库池将长时间保持连接，这意味着新的只读副本不会\xe2\x80\x99 被触及

\n\n

如果我们的服务器数量较少，\xe2\x80\x93 就会不平衡，我们对此无能为力\xe2\x80\x99。

\n\n

6) 关于你可以做什么的想法
\n A) 使用 dig 验证你自己是否获得了正确的 DNS 解析，并且每 5 秒在副本之间保持轮换。
\n如果你不这样做\xe2\x80\x99t，这是你需要修复的问题

\n\n

B) 定期回收数据库客户端
\n新的副本将被使用，虽然您会不平衡，但这将通过不断更改而有所帮助。\n但重要的是您不能同时回收所有客户端。否则，您将面临所有人获得相同时间的风险。我建议为每个客户端做一些随机 ttl（在最小/最大范围内）。

\n\n

C) 自己管理

\n\n

摘要：连接时，直接连接到连接最少/CPU 最低的只读副本。

\n\n

你如何做到这一点有点不简单。我建议使用 lambda 函数将该连接字符串保留在可查询的位置。让它以一定的频率更新。我想说更新首选数据库的频率是回收数据库连接频率的 1/10。如果数据库运行类似，您可以添加逻辑，您给出只读终点......并且仅在存在严重不平等时才给出显式终点。
\n我要提醒你，当出现新实例时，你要小心浮动。

\n\n

D) 增加客户端数量或只读副本数量

\n\n

这两者都会减少两个盒子出现显着差异的机会。

\n