[
https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428242#comment-17428242
]
Josh McKenzie commented on CASSANDRA-17032:
-------------------------------------------
{quote}I wonder if we should not make quotas a keyspace schema option, so quota
updates are automatically broadcasted to all nodes?
{quote}
We get the "broadcast to all nodes" plus side with the "now exposed to all the
problems of our non-transactional and inconsistent metadata" problems.
In the tradeoff between "you can deterministically change this during
firefighting" and "you can configure this more easily up front", I lean towards
the former even with all the warts, operating under the assumption most
operators have some tooling to do cluster-wide JMX and nodetool operations at
this point.
Ideally we wouldn't have that tradeoff but we're not there yet.
> 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]
