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

XMLWordPrintableJSON

    • 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
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Matthew Saltz (Inactive)
            Reporter:
            Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: