[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:
Duplicate
is duplicated by SERVER-39416 Limit the size of an individual Mongo... Closed
Related
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Case:

 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 ]

 It's not clear what this ticket would be for other storage engines such as WiredTiger...

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?

Generated at Thu Feb 08 03:23:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.