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

Rollback via refetch should only set collection options on local collection if they are non-empty

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.0-rc0
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Hide
      /*
       * Test basic 'renameCollection' rollback.
       */
      load("jstests/replsets/libs/rollback_test.js");
      
      (function() {
          "use strict";
      
          let testName = "rollback_rename";
          let dbName = testName;
      
          // Operations that will be present on both nodes, before the common point.
          let CommonOps = (node) => {
              let testDB = node.getDB(dbName);
              assert.commandWorked(testDB.createCollection("renameOpCollSource"));
          };
      
          // Operations that will be performed on the rollback node past the common point.
          let RollbackOps = (node) => {
              let testDB = node.getDB(dbName);
              assert.commandWorked(testDB["renameOpCollSource"].renameCollection("renameOpCollDest"));
          };
      
          // Set up Rollback Test.
          let rollbackTest = new RollbackTest(testName);
          CommonOps(rollbackTest.getPrimary());
      
          let rollbackNode = rollbackTest.transitionToRollbackOperations();
          RollbackOps(rollbackNode);
      
          rollbackTest.transitionToSyncSourceOperations();
      
          // Wait for rollback to finish.
          rollbackTest.transitionToSteadyStateOperations({waitForRollback: true});
      
          // Check the replica set.
          rollbackTest.stop();
      })();
      
      

      This bug can also be demonstrated by adding a checkReplicatedDataHashes to the end of the existing rollback3.js test.

      Show
      /* * Test basic 'renameCollection' rollback. */ load( "jstests/replsets/libs/rollback_test.js" ); ( function () { "use strict" ; let testName = "rollback_rename" ; let dbName = testName; // Operations that will be present on both nodes, before the common point. let CommonOps = (node) => { let testDB = node.getDB(dbName); assert.commandWorked(testDB.createCollection( "renameOpCollSource" )); }; // Operations that will be performed on the rollback node past the common point. let RollbackOps = (node) => { let testDB = node.getDB(dbName); assert.commandWorked(testDB[ "renameOpCollSource" ].renameCollection( "renameOpCollDest" )); }; // Set up Rollback Test. let rollbackTest = new RollbackTest(testName); CommonOps(rollbackTest.getPrimary()); let rollbackNode = rollbackTest.transitionToRollbackOperations(); RollbackOps(rollbackNode); rollbackTest.transitionToSyncSourceOperations(); // Wait for rollback to finish. rollbackTest.transitionToSteadyStateOperations({waitForRollback: true }); // Check the replica set. rollbackTest.stop(); })(); This bug can also be demonstrated by adding a checkReplicatedDataHashes to the end of the existing rollback3.js test.
    • Repl 2017-10-02, Repl 2017-10-23

      In rs_rollback.cpp, we resync metadata from certain collections if we need to, and then we update the CollectionOptions of our local collections here. It is possible for options validator, validationAction, validationLevel to be empty, but we don't check for that. So, if we call setValidationAction, for example, with an empty string, it actually sets it to the default validationAction, making our local collection options inconsistent with the upstream rollback node.

      For all collection options, we should only be setting them locally if the option we re-synced was non-empty.

      This seems to affect both the rollbackViaRefetch and the rollbackViaRefetchNoUUID algorithms. The rollbackViaRefetchNoUUID algorithm contains the same core logic as the 3.4 rollback algorithm, so it should affect v3.4 as well.

            Assignee:
            william.schultz@mongodb.com William Schultz (Inactive)
            Reporter:
            william.schultz@mongodb.com William Schultz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: