在最近的 AWS Aurora MySQL 数据库引擎自动更新后，还有其他人遇到问题吗？（特别是“5.7.mysql_aurora.2.10.3“)
- 上周末，我们的网络服务器开始报告问题，有时甚至变得无响应。
- 今天的故障排除表明，自周四早上以来，我们在之前运行负载非常轻的 AWS Aurora 数据库上定期达到 max_connections=80。
进一步挖掘发现，DatabaseConnections 指标出现了两个阶段性变化（见图 1）
- 5 月 25 日的最新步骤变更对应于 DB 期间的自动 DB 引擎升级 (5.7.mysql_aurora.2.10.3 --> 5.7.mysql_aurora.2.11.2)实例维护窗口...
- ...5 月 7 日的早期步骤更改对应于早期 DB 期间的未知更改簇维护窗口。
其他因素：
- CPU 使用率仅受到轻微影响（见图 2）
- DB 查询和使用模式保持不变。
- 没有什么特别有趣的发行说明用于此数据库引擎更新。
我们已经采取了一些解决方法，但看起来最近的 Aurora MySQL DB 引擎更新中的某些内容对性能产生了不利影响，我很想听听可能遇到类似问题的其他人的意见……以及您可能找到的任何解决方案。
编辑 6/6/2023
这个 Aurora DB 似乎现在已经神奇地自我修复了（具有讽刺意味的是，在另一个集群维护窗口期间） - 见下图：
注意：根据对我们 Web 服务器的分析，我们将旧 Web 服务器从 BlueHost（美国）迁移到 AWS（悉尼），以尝试应对性能不佳的 Aurora 实例。此次迁移于 6 月 2 日实施，性能得到了显著提升……但在 6 月 4 日的集群维护时段，数据库又神奇地恢复到中断前的性能！
以下是最终的前后对比图：
我希望能找到一种方法来审核每个 Aurora 维护窗口期间所做的事情！
答案1
请放心，您并不孤单。最近，我收到了一封来自 AWS 的电子邮件，敦促我在 6 月 30 日之前将我的 Aurora MySQL 升级到引擎 2.11.2。
然而，升级之后，我注意到磁盘 I/O 和提交延迟等各方面的性能都有明显下降。
为了解决这个问题，我通过电子邮件联系了 AWS 支持。他们的回复只是建议“分析表”。遗憾的是，尽管我听从了他们的建议，但情况并没有改善，反而继续引发许多问题。
答案2
我们也面临类似的问题，我们将 Aurora 集群从 2.11.1 升级到 2.11.2。升级前，我们通常一次有大约 30 - 50 个会话，但升级后，它面临严重破坏。会话数已达到 300 +。如果您使用“INSERT IGNORE”和“INSERT ON DUPLICATE KEY”语句，AWS 有一个内部修复程序可供应用。2.11.2 版本肯定存在性能问题。我们仍然面临这个问题，即使升级实例也无法解决问题。