[
https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427898#comment-17427898
]
Josh McKenzie commented on CASSANDRA-17032:
-------------------------------------------
{quote}I wonder if we should send quota exceeded warnings at the 65%, 75%, 85%
marks (configurable)
{quote}
Was thinking along the same lines this morning. So if we add:
* A soft cap (configurable per Keyspace)
* A hard cap (configurable per Keyspace) (effectively this is all this first
iteration does)
* More visible behavior when at various caps (log warning, diag event(s),
client warnings)
* Maybe a couple JMX hooks to both set quota sizes and to reload quotas from
CQL (break glass for operators)
That'd make it a much more flexible feature, and also give us the best of both
worlds (lazy reactive eval on the way up so no read-before-write, then ability
to deterministically change it if needed for operators when things are back in
line). wdyt [~paulo]?
> Allow configuring max allowable disk usage quota by keyspace
> ------------------------------------------------------------
>
> Key: CASSANDRA-17032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17032
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
>
> This is a similar idea (basically identical idea; didn't want to steamroll
> that old ticket w/an update to description etc) to what was raised and closed
> in CASSANDRA-5394. In multi-tenant situations it can be very helpful to
> provide disk quotas per Keyspaces for users.
> We can do this via a low priority background job that periodically checks
> disk usage and flips a bit on the Keyspaces when it's over as well as reverts
> it when things settle back down to prevent needing the read-before-write a
> hard realtime requirement would introduce. While this would of course allow
> users to "burst" their usage past that limit in the time window, it would
> still be sufficient for many use-cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
