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

Question

我们正在使用 AWS Aurora 作为数据库运行基于 REST API 的 spring boot 应用程序。我们的应用程序连接到只读的 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

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

1) 您看到的行为复制了负载均衡器的错误路由逻辑
这并不会让您感到惊讶，但这过去在小型 Web 服务器部署中更为常见——尤其是长时间运行的查询。使用连接池，您可以反射(reflect)这种情况。

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

可能的选项是 route53 或 NLB。我最好的猜测是他们正在使用 NLB。 NLBs 在 2017 年第三季度才对我们可用，而 Aurora 是 2 年前，但这仍然是一个合理的猜测。NLB 可以让我们根据最少的连接数进行平衡(比循环法要好得多)。

3) 验证假设
如果正在使用 route53，那么我们将能够使用 DNS 来查找。我对 route53 端点进行了挖掘，发现它给了我一个答案

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

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

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

你可以看到只读端点给我一个 CNAME 结果给

Zzz 是我的集群的名称，yyy 来 self 的 cloudformation 堆栈结构，yyy 来自 amazon。

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

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

4) Route53 负载均衡
他们可能会在所有健康的只读副本上设置 Route53 循环。
TTL 可能是 5s。健康节点将被删除，但没有基于

的平衡

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

如果我们的服务器数量较少，我们将失去平衡——我们对此无能为力。

6) 关于你能做什么的想法
A) 通过 dig 验证自己是否获得了正确的 DNS 解析，并且每 5 秒在副本之间轮换一次。
如果你不这样做，这是你需要解决的问题

B) 定期回收数据库客户端
新的副本将被使用，虽然你会不平衡，但这将有助于保持变化。但关键是您不能让所有客户同时回收。否则，您将面临所有人都获得相同时间的风险。我建议为每个客户做一些随机 ttl(在最小/最大范围内)。

C) 自己管理

总结:连接时，直接连接到具有最少连接/最低 CPU 的只读副本。

如何做到这一点并不简单。我建议使用 lambda 函数将此连接字符串保存在可查询的位置。让它以一定的频率更新。我会说更新首选数据库的频率是您回收数据库连接的频率的 1/10。如果数据库运行相似，您可以添加逻辑，您给出只读端点..并且只在存在显着不平等时给出一个明确的端点。
当出现新实例时，我会提醒您注意 float 。

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

这两者都会降低两个框出现显着差异的可能性。