-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
Repl 2017-07-31
Since SERVER-29277, the dropDatabase waits for all collection drops to complete before removing the entry for the database from the catalog. To do this, the free function mongo::dropDatabase() needs to call either ReplicationCoordinator::awaitReplicationOfLastOpForClient() or ReplicationCoordinator::awaitReplication(). However, these functions fail when dropDatabase() is called from within an applyOps operation because applyOps executes all its given operations while holding the global lock.
To reproduce:
db.adminCommand({applyOps: [{op: 'c', ns: 'test.$cmd', o: {create: 't'}}, {op: 'c', ns: 'test.$cmd', o: {drop: 't'}}, {op: 'c', ns: 'test.$cmd', o: {dropDatabase: 1}}]})
- is related to
-
SERVER-29277 Two Phase Drops: implement dropDatabase changes to support 2-phase drops
- Closed
- related to
-
SERVER-31436 dropDatabase must check `ReplicationCoordinator::canAcceptWritesFor` after reacquiring global lock
- Closed
-
SERVER-43458 Remove TempRelease in dropDatabase
- Closed
-
SERVER-29802 Non-atomic applyOps command should not take out a global exclusive lock
- Closed