Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-74415

SdamServerSelector Does Not Respect ReadPreference minClusterTime

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Sharding EMEA
    • ALL
    • Hide 
      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());
}
      Show
      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()); }
    • 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.

            Assignee:
            marcos.grillo@mongodb.com Marcos José Grillo Ramirez
            Reporter:
            brett.nawrocki@mongodb.com Brett Nawrocki
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: