-
Type: Improvement
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Execution
-
135
The server supports many database level commands, but in the storage execution layer those mostly devolve to scanning the CollectionCatalog. Keeping the DatabaseHolder in-memory state in sync with the CollectionCatalog is buggy. Today dropDatabase majority commits dropCollection oplog entries, then as a second step writes the dropDatabase oplog entry and clears the in-memory state.
Perhaps we don't need to write dropDatabase anymore. Sharding does a bunch of writes to clear database level state in its own config, regardless of the dropDatabase oplog entry.
- related to
-
SERVER-74703 Primary running dropDatabase may fail to finish database drop after replicating it due to a step down
- Closed
-
SERVER-77278 Replication rollback of a dropDatabase oplog entries leaves the in-memory database closed on the primary but open on secondaries, leading to secondaries crashing on receipt of conflicting database name
- Closed
-
SERVER-42053 proactively drop newly empty databases (sharding)
- Closed
-
SERVER-43890 Remove two-phase database drops
- Closed
-
SERVER-43925 Proactively close newly empty databases
- Needs Scheduling