[DRIVERS-2114] Unclear whether read preference must be sent in RS topologies Created: 05/Jul/19  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to RUBY-1834 Only send $readPreference in replica ... Closed
related to DRIVERS-2050 Duplicate read preference specifications Backlog
Driver Changes: Needed

 Description   

https://jira.mongodb.org/browse/SPEC-1292 prohibited sending read preference in standalone topologies. The server selection spec explicitly states how read preference should be passed to mongos. However when it comes to replica sets, read preference passing is not mentioned at all - it is neither required nor prohibited (e.g. in https://github.com/mongodb/specifications/blob/master/source/server-selection/server-selection.rst#read-preference).

matt.broadstone Suggested that read preference should not be sent when in RS topologies. When I tried that, a number of transactions tests failed. Examining these tests e.g. https://github.com/mongodb/specifications/blob/master/source/transactions/tests/read-pref.yml, they contain read preference assertions and specify they should be run on RS and sharded topologies. Hence there appears to be an implicit requirement that drivers send read preferences when in RS topologies.



 Comments   
Comment by Jeremy Mikola [ 18/May/20 ]

With OP_QUERY, the slaveOk bit was necessary for a secondary to respond to a query; however, $readPreference seems to have no purpose outside of mongos. AFAIK, a replica set member will simply ignore this field.

Is there any benefit for mandating that drivers include it for all non-standalone OP_MSG recipients, other than allowing drivers to utilize the same code path for replica sets and mongos when building an OP_MSG structure?

Comment by Rathi Gnanasekaran [ 09/Jul/19 ]

Will tackle after 4.2 work.

Comment by David Golden [ 08/Jul/19 ]

This was never well-specified during the OP_MSG work. I believe it should all be rewritten to clarify the differences between OP_QUERY and OP_MSG:

  • Topology Single
    • As currently specified
  • Topology ReplicaSet (with/without primary)
    • OP_MSG: send $readPreference always
    • OP_QUERY: never send $readPreference; set SlaveOK bit for non-primary read preference
  • Topology Sharded
    • OP_MSG: always send $readPreference
    • OP_QUERY: always send $readPreference; set SlaveOK bit for non-primary read preference

I believe the legacy behavior of using only SlaveOK and not sending $readPreference to a mongos for "secondaryPreferred" can be dispensed with.

Comment by Matt Broadstone [ 06/Jul/19 ]

Hey oleg.pudeyev, I've been thinking more about this and I think its probably the correct behavior to send $readPreference when connected to replicasets (and of course for mongos). Like we were talking about the other day, upon first reflection the read preference is only a useful hint for a mongos since it informs the router how to make its own server selection. However, with OP_MSG we have lost the slaveOk bit which gives a node in a replicaset an opportunity to let the client know it's "not master". Sending the $readPreference along with messages to a replicaset gives us the opportunity to maintain this behavior in the absence of the slaveOk bit.

All of this is cryptically described in the OP_MSG specification in the Global Command Arguments, with the somewhat unhelpful sentence:

and also whether a secondary server permits reads or responds "not master"

I would be supportive of improving this language, in particular to clarify why we want consistent command shapes for non-standalone connections, etc.

Generated at Thu Feb 08 08:24:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.