-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding EMEA
-
ALL
-
-
Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03, Sharding EMEA 2023-04-17
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 SERVER-74409.
- duplicates
-
SERVER-74281 Only attach minClusterTime read preference for sharding catalog operations
- Closed
- related to
-
SERVER-74409 StreamableReplicaSetMonitor::getHostsOrRefresh Can Return Out of Date Information
- Closed
-
SERVER-74568 SdamServerSelector sometimes doesn't fully respect client readPreference for config shard
- Closed