[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. |