[SERVER-1830] Support database-level granularity for fsync / lock Created: 22/Sep/10  Updated: 06/Dec/22  Resolved: 06/Oct/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: William Shulman Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Participants:

 Description   

I would like to be able to fsync / lock a particular db in a way that is isolated to that db (i.e. other dbs dont lock).



 Comments   
Comment by Eric Milkie [ 06/Oct/17 ]

This isn't something that we'll be able to provide with the current architecture. That said, the use cases for running "fsync / lock" have been diminishing in recent releases.

Comment by William Shulman [ 22/Sep/10 ]

That's a good point about the oplog. There are a family of related "features" that I personally would like to see that offer db-level granularity for what are currently server-level operations or concepts. Another is an extension of the --only replication option to allow for a list of dbs to replicate vs all or one. I am also vaguely aware of plans to make the overall concurrency / locking model for the server more fine-grained to be at the db or even collection level. Not sure if any or all of these might benefit from separating the oplogs to be per db, although I have not thought through what the drawbacks would be.

Comment by Eliot Horowitz (Inactive) [ 22/Sep/10 ]

Not sure about this.
A bit strange since there is the oplog that is shared, etc...

Generated at Thu Feb 08 02:58:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.