Repair Cassandra or DSE clusters in Kubernetes
This topic describes repair options for Apache Cassandra® clusters that are deployed in Kubernetes.
Use Cassandra Reaper to repair Cassandra clusters
For Cassandra clusters deployed and managed by the Kubernetes Operator for Apache Cassandra in Kubernetes, use Cassandra Reaper to schedule and orchestrate repairs. This feature is applicable to Cassandra databases only.
Reaper improves the existing nodetool repair process for Cassandra by:
-
Splitting repair jobs into smaller, tunable segments.
-
Handling back-pressure through monitoring running repairs and pending compactions.
-
Adding the ability to pause or cancel repairs and track progress precisely.
Reaper provides a REST API, a command-line tool, and a web UI. For instructions on how to build, install, and configure Reaper, see the Reaper documentation.
Reaper support was introduced in Cassandra Operator version 1.3.0. If you previously deployed the Cassandra Operator using earlier releases, then apply the latest YAML manifest to your Kubernetes (K8) cluster from a local machine where you have an established connection. For more information, see Upgrade the Cassandra Operator and related resources in Kubernetes.
-
To enable Reaper for the Cassandra Operator, update your datacenter configuration.
You can edit a local copy and use
kubectl apply -f <filename>, or invoke an editor to perform the changes directly in the Cassandra cluster that is running in Kubernetes. For the latter option, from your local machine where you have already established a connection with your Kubernetes cluster, enter a command such as:kubectl -n cass-operator edit cassdc dc1 -
When the editor starts, add the following YAML lines within the
spec:section, maintaining the YAML indentation:spec: reaper: enabled:trueAfter applying or saving the edited datacenter definition, the Cassandra Operator applies the updated configuration dynamically to the target Cassandra cluster.
-
After a few minutes, check the status of the pods:
kubectl -n cass-operator get podsIf the repair is complete, all pods should report fully
READYand inRunningstatus:NAME READY STATUS RESTARTS AGE cass-operator-78884f4f84-25fx5 1/1 Running 0 25d cluster1-dc1-default-sts-0 2/2 Running 0 21d cluster1-dc1-default-sts-1 2/2 Running 0 21d cluster1-dc1-default-sts-2 2/2 Running 0 2m48s -
Check your YAML file:
kubectl -n cass-operator get pod/cluster1-dc1-default-sts-2 -o yaml -
View the log file after the YAML configuration update:
kubectl -n cass-operator logs cluster1-dc1-default-sts-2 server-system-logger
Use NodeSync to repair DSE clusters
For DSE clusters deployed and managed by the Cassandra Operator in Kubernetes, use NodeSync, which is a continuous background repair service that is declarative and self-orchestrating.
After deploying a DSE cluster in your Kubernetes environment, use nodesyncservice enable to opt in new keyspaces and tables that you create.
