[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:
Duplicate
duplicates SERVER-74281 Only attach minClusterTime read prefe... Closed
Related
related to SERVER-74409 StreamableReplicaSetMonitor::getHosts... Closed
related to SERVER-74568 SdamServerSelector sometimes doesn't ... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Steps To Reproduce:

TEST_F(ServerSelectorTestFixture,
       ShouldNotSelectWhenPrimaryOpTimeIsEarlierThanMinClusterTimeAndPrimaryOnly) {
    TopologyStateMachine stateMachine(sdamConfiguration);
    auto topologyDescription = std::make_shared<TopologyDescription>(sdamConfiguration);
 
    const auto oldOptime = repl::OpTime\{Timestamp{1, 1}, 1};
    const auto newOptime = repl::OpTime\{Timestamp{2, 1}, 1};
 
    const auto s0 = ServerDescriptionBuilder()
                        .withAddress(HostAndPort("s0"))
                        .withType(ServerType::kRSPrimary)
                        .withLastUpdateTime(Date_t::now())
                        .withLastWriteDate(Date_t::now())
                        .withRtt(sdamConfiguration.getLocalThreshold())
                        .withSetName("set")
                        .withHost(HostAndPort("s0"))
                        .withHost(HostAndPort("s1"))
                        .withMinWireVersion(WireVersion::SUPPORTS_OP_MSG)
                        .withMaxWireVersion(WireVersion::LATEST_WIRE_VERSION)
                        .withElectionId(kOidOne)
                        .withSetVersion(100)
                        .withOpTime(oldOptime)
                        .instance();
    stateMachine.onServerDescription(*topologyDescription, s0);
 
    auto readPref = ReadPreferenceSetting(ReadPreference::PrimaryOnly);
    readPref.minClusterTime = newOptime.getTimestamp();
 
    auto server = selector.selectServer(topologyDescription, readPref);
    ASSERT_FALSE(server.has_value());
}

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 SERVER-74409.



 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 SERVER-74281.

Generated at Thu Feb 08 06:27:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.