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

May not be inside required WriteUnitOfWork when writing multikey index keys during initial sync data cloning

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.2.0-rc4
    • Fix Version/s: 4.2.1, 4.3.1, 4.0.15
    • Component/s: Replication
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2, v4.0
    • Steps To Reproduce:
      Hide

      (function() {
          "use strict";
       
          // Set up replica set.
          var testName = "repro";
          var dbName = testName;
          var replTest = new ReplSetTest({name: testName, nodes: 1});
          replTest.startSet();
          replTest.initiate();
       
          var primary = replTest.getPrimary();
          var primaryDB = primary.getDB(dbName);
          var collName = "multikey_coll";
       
          jsTestLog("Creating collection and index.");
          assert.commandWorked(primaryDB.createCollection(collName));
          assert.commandWorked(primaryDB[collName].createIndex({"x": 1}, {background: true}));
       
          // Make multikey with some docs.
          primaryDB[collName].insert({x: [1, 2]});
          primaryDB[collName].insert({x: [1, 2]});
          primaryDB[collName].insert({x: [1, 2]});
          assert.commandWorked(primaryDB.adminCommand({setFeatureCompatibilityVersion: "4.0"}));
       
          // Add a SECONDARY node. It should use batchSize=2 for its initial sync queries.
          jsTestLog("Adding secondary node.");
          replTest.add();
       
          // Let the SECONDARY begin initial sync.
          jsTestLog("Re-initiating replica set with new secondary.");
          replTest.reInitiate();
       
          // Wait until initial sync completes.
          replTest.awaitSecondaryNodes();
          replTest.awaitReplication();
          replTest.stopSet();
      })();
      
      

      Show
      ( function () { "use strict" ;   // Set up replica set. var testName = "repro" ; var dbName = testName; var replTest = new ReplSetTest({name: testName, nodes: 1}); replTest.startSet(); replTest.initiate();   var primary = replTest.getPrimary(); var primaryDB = primary.getDB(dbName); var collName = "multikey_coll" ;   jsTestLog( "Creating collection and index." ); assert.commandWorked(primaryDB.createCollection(collName)); assert.commandWorked(primaryDB[collName].createIndex({ "x" : 1}, {background: true }));   // Make multikey with some docs. primaryDB[collName].insert({x: [1, 2]}); primaryDB[collName].insert({x: [1, 2]}); primaryDB[collName].insert({x: [1, 2]}); assert.commandWorked(primaryDB.adminCommand({setFeatureCompatibilityVersion: "4.0" }));   // Add a SECONDARY node. It should use batchSize=2 for its initial sync queries. jsTestLog( "Adding secondary node." ); replTest.add();   // Let the SECONDARY begin initial sync. jsTestLog( "Re-initiating replica set with new secondary." ); replTest.reInitiate();   // Wait until initial sync completes. replTest.awaitSecondaryNodes(); replTest.awaitReplication(); replTest.stopSet(); })();
    • Sprint:
      Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07
    • Case:
    • Linked BF Score:
      0

      Description

      During initial sync collection cloning, we insert documents via the CollectionBulkLoader, which also inserts index keys. When we insert keys into an external sorter here, we are not inside a WriteUnitOfWork. Normally this is safe, since we will only be doing in-memory writes through the BulkBuilder, but if we are in FCV=4.0 and the index build is done using the Background method, then we will not use the bulk builder, and instead go through the IndexAccessMethod, which may in fact write to the storage layer if we are updating a multikey index. We need to make sure that we are enclosing these writes inside a WUOW in case they end up writing to storage.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              william.schultz William Schultz (Inactive)
              Reporter:
              william.schultz William Schultz (Inactive)
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: