DBCursor.getServerAddress 是否按我的预期工作？答案

【问题标题】：Does DBCursor.getServerAddress work as I expect?DBCursor.getServerAddress 是否按我的预期工作？
【发布时间】：2014-02-21 07:00:32
【问题描述】：

我希望getServerAddress 返回实际处理查询的 Mongo 服务器（副本集节点之一）的地址。

我正在记录 getServerAddress 的输出并且只看到 primary 地址，尽管我非常确定某些查询是由 secondary 处理的.

我有点困惑，因为我在 secondary 中看到查询（已设置 profillingLevel），而 getServerAddress 返回 primary。也许我错了……

这可能是 API 中的错误吗？有人遇到这样的问题吗？ getServerAddress 是否有可能总是返回 primary 而某些查询实际上由 secondaries 处理？

【问题讨论】：

您需要将您的 readPrefernce 指定为 secondaryPreffered ，即使如此，tag set 也可能对此产生影响。请参阅文档。您的问题中缺少此信息。所以我们需要更多地了解你的配置才能回答。
我的问题是关于 API 的。我只是想知道 API 是否完全按照我的预期工作。也就是说，它总是返回实际处理查询的节点的地址。我很困惑，因为 API 和分析显示不同的东西，但我可能弄错了......
在第二个想法我可能应该改写这个问题。
我的评论是关于“除非你包含关于你的readPreference、服务器配置、可能的标签集在你的问题中的信息没有人可以评论您在调用中看到的行为。API 应响应实际发生的情况。
“最近的”阅读偏好被微妙地破坏了。它并不总是做你期望它做的事情。你最好不要依赖它。

【解决方案1】：

我希望 getServerAddress 返回实际处理查询的 Mongo 服务器（副本集节点之一）的地址。

这个期望应该是正确的：DBCursor.java:getServerAddress() 返回当前游标的主机值。

我正在记录 getServerAddress 的输出，并且只看到主地址，尽管我很确定某些查询是由辅助地址处理的。

默认情况下，所有查询都转到副本集的主节点。如果您没有在应用程序代码中明确指定任何 secondary read preferences，则辅助节点上的查询来自其他来源。

由于您在问题上提到在 cmets 中使用 nearest 读取首选项，因此读取查询应该有利于副本集的最近（按网络延迟）成员。最近的成员可以是次要成员或主要成员。

MongoDB 手册中有更多关于Member Selection 的信息以供阅读偏好。

您有几个选项来检查查询的来源：

作为快速检查，运行 mongostat --discover 以观察整个副本集的读取活动，以查看复制之外是否确实存在辅助读取活动。或者，您也可以通过免费的MongoDB Management Service (MMS) 等监控服务查看此历史记录。
检查辅助服务器上的服务器日志以获取来自应用服务器 IP 的连接。除非您设置了--quiet logging mode，否则您应该会看到记录的新连接类似于：

[initandlisten] 接受来自 127.0.0.1:53548 #1234 的连接（现在打开 29 个连接）
登录到您的辅助服务器并运行db.currentOp()；您应该会看到来自应用服务器的查询（由 currentOp 信息中的client IP 标识）。

【讨论】：

感谢您深入而详细的回答。这真的很有帮助。我是Mongo 的新人，正在尝试解决我们在生产中使用基于Mongo 的应用程序时遇到的几个问题。
@Michael：如果你不确定，一定要问更多问题。有很多东西要学，但有一个有用的社区和来自 MongoDB, Inc（我目前工作的地方 :) 的支持。仅供参考，如果您有不适合 StackExchange 网站问答格式的问题，还有一个 mongodb-user discussion group。 MongoDB 团队成员在这两个论坛中都很活跃。您可能还想检查您附近是否有活跃的MongoDB User Group (MUG)；有很多来访工程师的“疯狂三月”之旅！
再次感谢您。我很快会问更多问题:))