[SERVER-74415] SdamServerSelector Does Not Respect ReadPreference minClusterTime Created: 27/Feb/23 Updated: 13/Apr/23 Resolved: 13/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Brett Nawrocki | Assignee: | Marcos José Grillo Ramirez |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
|||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||
| Sprint: | Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03, Sharding EMEA 2023-04-17 | |||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||
| Description |
|
When making requests to the config server on the config or admin databases, the current config time is added to the read preference as minClusterTime. However, when selecting servers using a PrimaryOnly read preference, the SdamServerSelector creates a new ReadPreference object with PrimaryOnly, but ignoring all other settings such as minClusterTime. This is further complicated by additional logic to explicitly ignore the minClusterTime if the server data is older than the provided minClusterTime. I'm not sure what the correct behavior is here, but it it seems that these layers are making assumptions about how the other layers work which do not match the actual implementations. I noticed this when investigating BF-27853, and this might contribute to the issue seen in |
| Comments |
| Comment by Marcos José Grillo Ramirez [ 13/Apr/23 ] |
|
As max.hirschhorn@mongodb.com pointed out using PrimaryOnly read preference make other options illegal, SERVER-74281 and SERVER-74568 already handle any correctness issues. It is worth to mention that the server selector tries to use a minClusterTime for non PrimaryOnly modes as pointed out in this comment. So there is no need to do any work in this ticket. |
| Comment by Max Hirschhorn [ 06/Apr/23 ] |
|
I wasn't sure the status of this ticket, yet I did want to mention {$readPreference: {mode: "primary"}} aka ReadPreference::PrimaryOnly is intended to ignore all other read preference options like maxStalenessSeconds, tags, and hedge. The driver specification requires returning an error if any of those options are specified to when mode == "primary". Although, for completeness, the erroring is mandated when the read preference is specified in application code directly and the validation isn't performed by all drivers consistently if the extra options are specified via the connection string (DRIVERS-1229). I think part of what is going on for minClusterTime is the server's validation required by the driver specification happens through ReadPreferenceSetting::fromInnerBSON() and ReadPreferenceSetting::fromInnerBSON() isn't how ReadPreferenceSetting object is being constructed always internally. Perhaps the logic in ShardRemote::_scheduleCommand() should only set minClusterTime when the mode != "primary"? CC wenqin.ye@mongodb.com who is working on |