Does DBCursor.getServerAddress work as I expect?

Question

I expect getServerAddress to return the address of the Mongo server (one of replica set nodes), which actually handles the query.

I am logging output of getServerAddress and see only the primary address although I am pretty sure that some queries are handled by secondary.

I am a little bit confused since I see queries (having set profillingLevel) in the secondary while getServerAddress returns the primary. Maybe I am mistaken though ...

Can it be a bug in the API ? Does anybody encounter such a problem ? Is it possible that getServerAddress always returns the primary while some queries are actually handled by secondaries ?

Answer 1

I expect getServerAddress to return the address of the Mongo server (one of replica set nodes), which actually handles the query.

This expectation should be correct: DBCursor.java:getServerAddress() returns the host value for the current cursor.

I am logging output of getServerAddress and see only the primary address although I am pretty sure that some queries are handled by secondary.

By default all queries go the primary of the replica set. If you have not explicitly specified any secondary read preferences in your application code, the queries on the secondary are coming from another source.

Since you mention using nearest read preference in comments on the question, read queries should favour a nearest (by network latency) member of the replica set. The nearest members can be either secondaries or the primary.

The MongoDB manual has more information on Member Selection for read preferences.

Checking the source of queries

You have several options to check the source of queries:

• As a quick check, run mongostat --discover to watch read activity across your replica set to see if there is actually secondary read activity outside of replication. Alternatively, you could also view this history through a monitoring service such as the free MongoDB Management Service (MMS).

• Check your server logs on the secondaries for connections from your app server IP(s). Unless you have set --quiet logging mode, you should see new connections logged similar to:

  [initandlisten] connection accepted from 127.0.0.1:53548 #1234 (29 connections now open)

• Login to your secondaries and run db.currentOp(); you should see queries from your application server (as identified by the client IP in the currentOp info).