Loading...

XML

Word

Printable

JSON

Details

Type: Improvement
Resolution: Unresolved
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
- techdebt

Assigned Teams:

Storage Execution
Linked BF Score:
135

Description

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.

Attachments

Issue Links

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-43890 Remove two-phase database drops

Backlog

SERVER-43925 Proactively close newly empty databases

Backlog

SERVER-42053 proactively drop newly empty databases (sharding)

Closed

Activity

People

Assignee:: Backlog - Storage Execution Team

Reporter:: Dianna Hohensee (Inactive)

Participants:: Backlog - Storage Execution Team, Dianna Hohensee

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: May 18 2023 05:40:04 PM UTC

Updated:: May 23 2023 03:49:03 PM UTC