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

Use a 1-node CSRS in non-stepdown sharding passthroughs tests

    • Fully Compatible
    • v3.6
    • TIG 2018-1-29, TIG 2018-02-12

      Akin to the idea behind SERVER-31670 of reducing the number of unexpected elections observed in our tests, I'd like to propose that we use

      • a 3-node CSRS where all nodes have votes=1 and priority=1 when the test suite attempts to step down the CSRS primary, and
      • a 1-node CSRS for all other cases.

      This would mean the following test suites would run with a 1-node CSRS

      • aggregation_sharded_collections_passthrough.yml
      • causally_consistent_jscore_passthrough.yml
      • causally_consistent_jscore_passthrough_auth.yml
      • change_streams_mongos_passthrough.yml
      • change_streams_sharded_collections_passthrough.yml
      • change_streams_secondary_reads.yml
      • integration_tests_sharded.yml
      • jstestfuzz_sharded.yml
      • jstestfuzz_sharded_causal_consistency.yml
      • jstestfuzz_sharded_session.yml
      • sharded_causally_consistent_jscore_passthrough.yml
      • sharded_collections_jscore_passthrough.yml
      • sharding_gle_auth_basics_passthrough.yml
      • sharding_jscore_op_query_passthrough.yml
      • sharding_jscore_passthrough.yml

      and only jstestfuzz_sharded_continuous_stepdown.yml would continue to use a 3-node replica set. Is the Sharding team agreeable to this proposal? I'd also be curious to know if this is something we'd consider doing for sharding-related tests that aren't interested in specifically how collection metadata operates are processed.

            robert.guo@mongodb.com Robert Guo (Inactive)
            max.hirschhorn@mongodb.com Max Hirschhorn
            0 Vote for this issue
            7 Start watching this issue