【问题标题】:mongodb i/o timeout when using clustered mongo instances使用集群 mongo 实例时 mongodb i/o 超时
【发布时间】:2019-04-30 10:50:46
【问题描述】:

我有一个应用程序正在使用 upper.io/db 包与 Mongo 数据库服务器进行通信(这是一个相当简单的 gopkg.in/mgo.v2 包装器)。应用程序的工作方式是它在启动时在主线程中创建一个会话,然后每个需要向 mongo 服务器发出请求的单独 go 例程在会话上调用 Clone 并在会话上执行 defer session.Close结果值。据我所知,这都是标准操作程序。

在我们使用本地运行的 MongoDB MongoLab 上的沙盒实例的开发环境中,此设置可以正常工作。最近,我们将应用程序提升到我们的暂存环境,在该环境中,应用程序与 MongoLab 上的 MongoDB 共享集群实例通信(最便宜的 15 美元选项)。这就是奇怪开始发生的地方。通过的 /first/ 请求(来自被调用的第一个 go-routine)返回预期的响应,但后续的都返回

 read tcp <ip address>:47112: i/o timeout

这既发生在我们指向集群的本地开发机器上,也发生在用于暂存环境的 AWS 主机上。由于 Mongo 集群来自 Mongolabs,我假设他们已经正确配置了所有内容。

代码有点无聊 TBH:它实际上只是在 main 函数中打开会话并维护对它的引用,然后有多个具有这种基本结构的 goroutine:

   sess := session.Clone()
   defer sess.Close()

   // make requests to Mongo

在测试期间,我什至限制它一次只运行一件事(即在任何给定时间只有一个 goroutine 处于活动状态),它仍然以同样的方式失败。

以前有人遇到过这种情况吗?我需要以特定方式配置 upper.io/db 吗?也许直接使用mgo?我对此束手无策:(

【问题讨论】:

  • 他们可能在集群中正确配置了它,但是 mongo 中的安全组和权限是否设置为允许从其他地方访问?他们应该把所有东西都锁起来了。
  • 当然,我可以从 mongo cli 客户端连接到集群。同样,对 Mongo 的第一个请求得到了成功响应,随后的请求超时。

标签: mongodb go mgo


【解决方案1】:

在一个相当漫长而艰苦的过程中,我们终于在我们的计划中找到了这个问题和类似问题的来源。它最终成为upper.io/db 库v1 版本中的会话泄漏。错误和修复是 outlined here,但是这个库的 v1 版本在这一点上已经过时了,以后的版本没有出现这个问题。

我怀疑这个答案对游戏这么晚的任何人都有用(尤其是因为我们自己像 3 年前一样解决了这个问题),但只是想把答案留在这里以保持完整性。

【讨论】:

    猜你喜欢
    • 2014-08-30
    • 2015-05-11
    • 1970-01-01
    • 2012-09-27
    • 2018-09-12
    • 1970-01-01
    • 2023-04-06
    • 2019-01-31
    • 1970-01-01
    相关资源
    最近更新 更多