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

SdamServerSelector Does Not Respect ReadPreference minClusterTime

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major - P3 Major - P3
    • None
    • None
    • 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

    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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: