[SERVER-10620] Facility to Limit Size of Database on a Per-Database Basis Created: 24/Aug/13 Updated: 06/Dec/22 Resolved: 04/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Sam Kleinman (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
e.g. the ability to set --quota --quotafiles on per-database basis. |
| Comments |
| Comment by Wahid Bhimji [ 12/Mar/21 ] |
|
I also have a multi user environment and some way to limit a database's size is essential. If it could be reopened it would be useful. |
| Comment by Jacob Horbulyk [ 06/Mar/19 ] |
I think it is quite clear: If there are multiple DBs on a single instance/cluster, it would be nice if the size of a single DB could be capped or otherwise limited. The use case is that if you have a DBs per tenant that is on a shared instance, it would be nice to limit the extent to which a big neighbor can affect the instance/clusters health. If you allow the ability to cap a DB based on max allowed disk size, this problem can be solved (even if mapping max allowed disk size to in-memory representation size is difficult). I would like to request that this issue be re-opened. |
| Comment by Eric Milkie [ 05/Mar/19 ] |
|
The issue is now marked as "gone away" because it extends an MMAPv1-only feature (disk quotas). It's not clear what this ticket would be for other storage engines such as WiredTiger, since unlike MMAPv1, physical disk space consumed is much less directly mappable from the collection size, due to the differences between in-memory and disk format, and due further to translation layers such as encryption and compression. |
| Comment by Jacob Horbulyk [ 05/Mar/19 ] |
|
Why was this issue closed? Is it going to be part of an upcoming release? |