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

`dropIndex` blocks secondary if it is executing `createIndexes` currently

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Replication
    • None
    • ALL
    • Hide

      To reproduce the questionable behavior we'll need:

      1. MongoDB replicaset with primary instance and at least one secondary instance.
      2. Sufficiently large collection t for enough time to be available for observation.
      3. Some index already built on that collection. E. g. db.t.createIndex({foo:1})

      Steps to reproduce are:

      1. Start building new index on the collection.
        db.t.createIndex({foo:1,_id:1})
      2. Wait until primary reports index build completion.
      3. Drop unique index before secondaries catch up with building new index. db.t.dropIndex('foo_1').
      Show
      To reproduce the questionable behavior we'll need: MongoDB replicaset with primary instance and at least one secondary instance. Sufficiently large collection t for enough time to be available for observation. Some index already built on that collection. E. g. db.t.createIndex({foo:1}) Steps to reproduce are: Start building new index on the collection. db.t.createIndex({foo:1,_id:1}) Wait until primary reports index build completion. Drop unique index before secondaries catch up with building new index. db.t.dropIndex('foo_1') .

      Observed behavior is:

      • Secondary mongod instances block on Global lock and effectively all operations except building index are waiting for Global lock.
      • Replication is effectively paused.
      • Due to replication pause all operations with writeConcern:majority on the primary instance are blocked. E. g. db.t.insertOne({foo:1}, {w:'majority'}) will hang until one of secondaries catch up with primary.
      • All read operations with readPreference set to secondaryPreferred also hang until indices are built on that secondary. E. g.
        db.getMongo().setReadPref('secondaryPreferred');
        db.t.find();
        will hang.

      Results of db.currentOp() from secondary instance with hanged db.t.find() are attached to the issue.

      This behavior is very surprising and isn't documented, so I consider it a bug.

        1. scratch_18.json
          10 kB
          Sergey Zagursky

            Assignee:
            kelsey.schubert@mongodb.com Kelsey Schubert
            Reporter:
            sz Sergey Zagursky
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: