如何解决 Rails （4） 应用程序中的 Aurora Autoscaling MySQL 读取器问题？

问：

尝试让我们的 rails （4） 应用程序在新的自动扩展的 Aurora MySQL 读取器联机时自动使用它们。

我们有一个 Rails 4 Web 应用程序，它目前在某些 EC2 实例上的静态环境中运行。Web 应用始终处于运行状态。Apache Passenger 配置为向上和向下扩展线程，但具有保持的最小线程池。我真的很想利用 Aurora 自动扩展，但由于连接是静态的，因此这是一个挑战。假设交通量回升并达到某个阈值，乘客启动了所需的额外线程。都很棒。但几分钟后，Aurora 达到了其自动缩放阈值并添加了一个新的读取器。没有一个线程实际上正在使用读取器，因为它们已经有了自己的连接。重新启动 Web 应用程序当然会使用新的阅读器，但这感觉很沉重且具有破坏性。我一直在使用 RDS Proxy 和/或 ProxySQL 以及 mysql 适配器上的 pool、idle_timeout 和 reaping_frequency 参数。似乎没有什么能让我达到应用程序可以动态使用（或停止使用）自动缩放阅读器的地步。

我正在考虑自定义适配器以优雅地刷新其连接作为下一步，但肯定存在现成的解决方案。我们打算在未来迁移到 Kubernetes，我想这会因为短暂性而解决它，但是我希望在那之前有一些工作。

成功解决此用例的人可以分享他们的解决方案吗？

更新

在我所有的测试中，我都无法将连接转移到新的阅读器上。一旦它与实例建立，它就会保留在该实例上。我们的 Web 应用程序是静态的，因此连接是半永久性的。在任何情况下，RDS 代理或 ProxySQL 中间件都无法开始将同一 Web 应用程序连接上的流量重定向到新的读取器。我能够通过从 Web 服务器端处理它来解决我的问题。我们使用 Phusion passenger，我编写了一个可怜的 mans rolling restart 脚本，它优雅地从池中删除线程，让它们完成处理，然后死亡。我们还没有开始使用它，但我们现在有选择。我们可以在 cron 上将其设置为定期运行，或者更好的是，挂接到云监视事件中，并在读取器进入或退出池时使用 lambda 手动运行脚本。