Skip to content

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Cassandra Repair Operations Guide

This guide covers the operational aspects of running and managing Cassandra repair: command syntax, scheduling strategies, monitoring, and troubleshooting. For the architectural foundations of how repair works — including Merkle trees, repair modes, and the gc_grace_seconds constraint — refer to the Repair Architecture page. For the broader context of replica synchronization mechanisms (hinted handoff, read reconciliation), see Replica Synchronization.

This operational guide addresses:

  • How to run repair - Command options and syntax
  • When to run repair - Scheduling within gc_grace_seconds
  • Which strategy to use - Sequential, parallel, or segmented approaches
  • How to monitor repair - Progress tracking and verification
  • How to troubleshoot - Common issues and resolutions

Repair must complete on all nodes within gc_grace_seconds to prevent deleted data from resurrecting.

ParameterDefaultSignificance
gc_grace_seconds864000 (10 days)Maximum time before tombstones are garbage collected

If a node misses a tombstone and repair does not propagate it before garbage collection, the deleted data reappears—known as “zombie data.” For detailed explanation of this mechanism, see Tombstones.


Operational concepts for repair execution:

  • Full vs incremental repair
  • Primary range repair (-pr)
  • Repaired vs unrepaired SSTables
  • Anti-compaction behavior
  • Table iteration during repair

Complete reference for all repair command options:

  • Scope options: -pr, -full, -st/-et
  • Parallelism options: -seq, -dcpar, -j (parallel is default)
  • Scope limiting: -dc, -local, -hosts
  • Operational options: --preview, --trace, -os

Implementation strategies for different environments:

  • Sequential single-node repair (small clusters)
  • Parallel multi-node repair (medium clusters)
  • Segmented subrange repair (large data volumes)
  • Continuous repair (large clusters)

Planning and maintaining repair schedules:

  • Timeline calculations
  • Schedule planning worksheets
  • Off-peak timing recommendations
  • Compliance monitoring
  • Handling disruptions

Terminal window
# Standard primary-range incremental repair (recommended for routine maintenance)
nodetool repair -pr my_keyspace
# Full repair after node recovery
nodetool repair -full my_keyspace
# Parallel repair is the default in Cassandra 4.0+
nodetool repair -pr my_keyspace
# Sequential repair for minimal impact
nodetool repair -pr -seq my_keyspace
# Repair specific table
nodetool repair -pr my_keyspace my_table
# Repair with multiple table threads
nodetool repair -pr -j 4 my_keyspace
# Preview repair without executing
nodetool repair -pr --preview my_keyspace
Terminal window
# Check active repair sessions
nodetool repair_admin list
# Monitor streaming progress
nodetool netstats | grep -i repair
# Check percent repaired
nodetool tablestats my_keyspace | grep -i "percent repaired"
# Cancel stuck repair
nodetool repair_admin cancel <repair_id>
When to Use Each Repair TypeWhen to Use Each Repair TypeRoutine maintenance?yesnoIncremental,primary rangeUse: nodetool repair -prNode replacement/recovery?yesnoFull repair,all dataUse: nodetool repair -fullInconsistency suspected?yesnoFull repair,primary rangeUse: nodetool repair -full -prUse: nodetool repair -pr

Cluster SizeData per NodeRecommended StrategyTypical Duration
3-6 nodes< 500 GBSequentialHours
6-20 nodes< 500 GBParallelHours
6-20 nodes> 500 GBSegmentedHours-Days
20-50 nodesAnyParallel + SegmentedDays
50+ nodesAnyContinuous (AxonOps)Ongoing

AxonOps Adaptive Repair provides automated repair scheduling with:

  • Intelligent scheduling across nodes
  • Load-aware throttling that adapts to cluster conditions
  • Automatic failure detection and retry
  • Progress monitoring and alerting
  • Repair history and gc_grace_seconds compliance tracking

  • Use -pr flag for routine maintenance
  • Schedule repairs during off-peak hours
  • Monitor repair completion and percent repaired metrics
  • Use automated tools for large clusters
  • Maintain buffer time before gc_grace_seconds deadline
  • Test repair procedures in non-production first
  • Running repair on all nodes simultaneously
  • Skipping repair for extended periods
  • Running repair during traffic spikes
  • Ignoring repair failures
  • Reducing gc_grace_seconds without faster repair cycles

Architecture (Theory):

Operations: