[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: |
|
||||||||||||||||
| 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:
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:
I would be supportive of improving this language, in particular to clarify why we want consistent command shapes for non-standalone connections, etc. |