[
https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428278#comment-17428278
]
Paulo Motta commented on CASSANDRA-17032:
-----------------------------------------
Another thought that ocurred to me is that we should probably make quota
validations at the replica end and not at the coordinator, for the following
reasons:
- prevent inconsistent quota enforcement depending on which coordinator
coordinates the request (ie. coordinator A is above quota but not coordinator B)
- support non-replica (ie. proxy) coordinators which is a common deployment
model and would not be supported if we always assume coordinators are also
replicas
This would make the patch a bit more involved in order to make the feature more
complete and predictable.
> 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]
