-
Type:
Bug
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.5.10
-
Component/s: Replication
-
Labels:None
-
Backwards Compatibility:Fully Compatible
-
Operating System:ALL
-
Epic Link:
-
Sprint: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 Complete TODO listed in SERVER-29802
-
- Open
-
-
SERVER-29802 Non-atomic applyOps command should not take out a global exclusive lock
-
- Closed
-