You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently don't have an automated way of expanding the storage capacity of Cassandra pods.
This can lead to tricky situations in production where storage is close to being full and cluster expansion would take too long to mitigate the issue.
In some cases, volume expansion will be possible if the storage class allows it, but there are cases where it will be faster to attach an additional volume to the pods and configure Cassandra to use it as additional data directory.
Scenario should be automated in cass-operator and handle manipulating the statefulsets to achieve this, removing the odds of misconfiguration and data loss.
Why is this needed?
It is common to run out of disk space with Cassandra under circumstances where either capacity planning hasn't been thought in advance or compaction and tombstone reclaiming isn't performing as expected.
We need to ensure that there's an easy path out of such critical situations in production.
### Requirements
- [ ] #609 Is implemented to allow metadata which volumes are used for data volume expansion
- [ ] Volumes are allowed to be modified in the StatefulSet
┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: CASS-14
The text was updated successfully, but these errors were encountered:
This should be split to two different tickets, as adding volumes is a very separate implementation detail. It's also related to #609 since currently additional volumes do not have indication what they're used for.
What is missing?
We currently don't have an automated way of expanding the storage capacity of Cassandra pods.
This can lead to tricky situations in production where storage is close to being full and cluster expansion would take too long to mitigate the issue.
In some cases, volume expansion will be possible if the storage class allows it, but there are cases where it will be faster to attach an additional volume to the pods and configure Cassandra to use it as additional data directory.
Scenario should be automated in cass-operator and handle manipulating the statefulsets to achieve this, removing the odds of misconfiguration and data loss.
Why is this needed?
It is common to run out of disk space with Cassandra under circumstances where either capacity planning hasn't been thought in advance or compaction and tombstone reclaiming isn't performing as expected.
We need to ensure that there's an easy path out of such critical situations in production.
┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: CASS-14
The text was updated successfully, but these errors were encountered: