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

Await replication before cloning in clone_catalog_data.js test

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 4.1.3
    • 3.7.9
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding 2018-07-30, Sharding 2018-08-13, Sharding 2018-09-10
    • 31

    Description

      A failure in clone_catalog_data.js is primarily caused because this command is meant to be called internally. When the command is run through movePrimary, the config's opTime will be gossiped. This gossiping guarantees that a stale read can't be run against the config server. When called directly, the shard running cloneCatalogData could potentially have an outdated version of the config's opTime, meaning that the requested majority commit point could be outdated as well. If the requested majority commit point is outdated, it could allow a config secondary to return outdated collection information. This happens here, causing the destination shard to create a collection it doesn't think exists yet – thus generating a new UUID in the cloning process. 

      The fix for the test is to await replication (or opTime committed) before attempting to call _cloneCatalogData.

      Attachments

        Activity

          People

            blake.oler@mongodb.com Blake Oler
            blake.oler@mongodb.com Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: