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

Await configRS optime replication before to stop it in lagged_config_secondary.js

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.9.0
    • Affects Version/s: 4.7.0
    • Component/s: Sharding
    • Labels:
    • Fully Compatible
    • ALL
    • Sharding 2020-10-19, Sharding 2020-11-02
    • 22

      In order to perform this insertion the mongos will try to fetch the collection information from the config replica set, it will use nearest read preference and a majority read concern with the lastest opTime he is aware of. Obviously this insertion could fail if the request hit a secondary node of the config repl that is not able to satisfy the specified majority read concern.

      The problem is that the test doesn't guarantees that the requested optime has been replicated to all secondaries when that insertion is executed, in fact between the awaitReplication and the stop of the replication on the config replica set, the opTime could be bumped on the mongos.

      In particular in the test we saw that the uptime reporter on the mongos could ran in this time window (from awaitReplication to stopReplication) and cause the optime to bump.

      The proposed solution is to move the awaitReplication just before the stopReplication call

            tommaso.tocci@mongodb.com Tommaso Tocci
            tommaso.tocci@mongodb.com Tommaso Tocci
            0 Vote for this issue
            1 Start watching this issue


                Error rendering 'slack.nextup.jira:slack-integration-plus'. Please contact your Jira administrators.