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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.7.0
    • Fix Version/s: 4.9.0
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2020-10-19, Sharding 2020-11-02
    • Linked BF Score:
      22

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              tommaso.tocci Tommaso Tocci
              Reporter:
              tommaso.tocci Tommaso Tocci
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: