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

Insertion into system.indexes on mongos causes 6 index builds on shard

    XMLWordPrintableJSON

Details

    • Fully Compatible
    • Hide

      (function() {
        let st = ShardingTest({shards: 1});
        let db = st.s.getDB("test");
        st.shard0.getDB("test").setLogLevel(1);
        assert.commandWorked(db.adminCommand({enableSharding: "test"}));
        assert.commandWorked(db.adminCommand({shardCollection: "test.coll", key: {_id: 1}}));
       
        // Fails.
        assert.commandWorked(db.system.indexes.insert({ns: "test.coll", v: 2, key: {_id: 1, a: 1}, name: "a_1"}));
       
        st.stop();
      })();
      

      Show
      (function() { let st = ShardingTest({shards: 1}); let db = st.s.getDB("test"); st.shard0.getDB("test").setLogLevel(1); assert.commandWorked(db.adminCommand({enableSharding: "test"})); assert.commandWorked(db.adminCommand({shardCollection: "test.coll", key: {_id: 1}}));   // Fails. assert.commandWorked(db.system.indexes.insert({ns: "test.coll", v: 2, key: {_id: 1, a: 1}, name: "a_1"}));   st.stop(); })();
    • Sharding 2018-04-23

    Description

      Attempting to create an index on a sharded collection using insertion into system.indexes fails with the following error:

      Error: write failed with error: {
       	"nInserted" : 0,
       	"writeError" : {
       		"code" : 82,
       		"errmsg" : "no progress was made executing batch write op in test.system.indexes after 5 rounds (0 ops completed in 6 rounds total)"
       	}
      

      It forward the insertion to the shard six times. Each time the shard creates the index, but then uasserts due to an epoch mismatch on system.indexes and reverts the index build.

      build index on: test.coll properties: { v: 2, key: { a: 1.0 }, name: "a_1", ns: "test.coll" }
      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
      bulk commit starting for index: a_1
      done building bottom layer, going to commit
      build index done.  scanned 0 total records. 0 secs
      User Assertion: StaleConfig{ ns: "test.system.indexes", vReceived: Timestamp(1, 0), vReceivedEpoch: ObjectId('5aa977e5b6b4bb7493628419'), vWanted: Timestamp(0, 0), vWantedEpoch: ObjectId('000000000000000000000000') }: shard version not ok: version epoch mismatch detected for test.system.indexes, the collection may have been dropped and recreated src/mongo/db/s/collection_sharding_state.cpp 260
      

      The shard does not end up with the index built. It seems acceptable for insertion into system.indexes to fail on mongos, but it would be better to not do index builds on the shard before failing.

      Attachments

        Activity

          People

            matthew.saltz@mongodb.com Matthew Saltz (Inactive)
            tess.avitabile@mongodb.com Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: