mongodb i/o 使用集群 mongo 实例时超时
mongodb i/o timeout when using clustered mongo instances
我有一个使用 upper.io/db 包与 Mongo 数据库服务器通信的应用程序（它是 gopkg.in/mgo.v2 的一个相当简单的包装器）。应用程序的工作方式是它在启动时在主线程中创建一个会话，然后每个需要向 mongo 服务器发出请求的例程在会话上调用 Clone 并执行结果值上的 defer session.Close。据我所知，这都是标准操作程序。
此设置在我们使用本地 运行 MongoDB 或 [=] 上的沙箱实例的开发环境中没有任何错误33=]实验室。最近，我们将该应用程序提升到我们的暂存环境，在那里我们让应用程序与 MongoLab 上的 MongoDB 的共享集群实例进行通信（最便宜的 15 美元选项）。这就是奇怪开始发生的地方。通过的 /first/ 请求（从被调用的第一个 go-routine 开始）返回预期的响应，但后续的都是 return
read tcp <ip address>:47112: i/o timeout
这既发生在我们指向集群的本地开发机器上，也发生在用于暂存环境的 AWS 主机上。由于 Mongo 集群来自 Mongolabs，我假设他们已经正确配置了所有内容。
代码有点无聊TBH：它实际上只是在主函数中打开会话并维护对它的引用，然后有多个具有这种基本结构的goroutines：
sess := session.Clone()
defer sess.Close()
// make requests to Mongo
在测试期间，我什至将它限制为 运行 一次只能做一件事（即在任何给定时间只有一个 goroutine 处于活动状态），但它仍然以同样的方式失败。
有人 运行 以前参与过这个吗？我需要以特定方式配置 upper.io/db 吗？也许直接使用mgo？我对此束手无策:(
在相当漫长而艰苦的过程中，我们终于找到了这个问题和类似问题在我们的程序中的来源。它最终成为 upper.io/db 库的 v1 版本中的会话泄漏。错误和修复是 outlined here，但是这个库的 v1 版本在这一点上已经过时了，以后的版本不会出现这个问题。
我怀疑这个答案对游戏这么晚的任何人都有用（特别是因为我们自己解决了它，就像.. 3 年前的这个时候），但只是想在这里留下答案的完整性。
我有一个使用 upper.io/db 包与 Mongo 数据库服务器通信的应用程序（它是 gopkg.in/mgo.v2 的一个相当简单的包装器）。应用程序的工作方式是它在启动时在主线程中创建一个会话，然后每个需要向 mongo 服务器发出请求的例程在会话上调用 Clone 并执行结果值上的 defer session.Close。据我所知，这都是标准操作程序。
此设置在我们使用本地 运行 MongoDB 或 [=] 上的沙箱实例的开发环境中没有任何错误33=]实验室。最近，我们将该应用程序提升到我们的暂存环境，在那里我们让应用程序与 MongoLab 上的 MongoDB 的共享集群实例进行通信（最便宜的 15 美元选项）。这就是奇怪开始发生的地方。通过的 /first/ 请求（从被调用的第一个 go-routine 开始）返回预期的响应，但后续的都是 return
read tcp <ip address>:47112: i/o timeout
这既发生在我们指向集群的本地开发机器上，也发生在用于暂存环境的 AWS 主机上。由于 Mongo 集群来自 Mongolabs，我假设他们已经正确配置了所有内容。
代码有点无聊TBH：它实际上只是在主函数中打开会话并维护对它的引用，然后有多个具有这种基本结构的goroutines：
sess := session.Clone()
defer sess.Close()
// make requests to Mongo
在测试期间，我什至将它限制为 运行 一次只能做一件事（即在任何给定时间只有一个 goroutine 处于活动状态），但它仍然以同样的方式失败。
有人 运行 以前参与过这个吗？我需要以特定方式配置 upper.io/db 吗？也许直接使用mgo？我对此束手无策:(
在相当漫长而艰苦的过程中，我们终于找到了这个问题和类似问题在我们的程序中的来源。它最终成为 upper.io/db 库的 v1 版本中的会话泄漏。错误和修复是 outlined here，但是这个库的 v1 版本在这一点上已经过时了，以后的版本不会出现这个问题。
我怀疑这个答案对游戏这么晚的任何人都有用（特别是因为我们自己解决了它，就像.. 3 年前的这个时候），但只是想在这里留下答案的完整性。