Skip to content

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

nodetool repair_admin

Manages and monitors repair sessions on the cluster.


Terminal window
nodetool [connection_options] repair_admin <list | cancel | cleanup | summarize-pending | summarize-repaired> [options]

See connection options for connection options.

nodetool repair_admin provides administrative control over repair sessions:

  • list: View active and recent repair sessions
  • cancel: Stop a running repair
  • cleanup: Clean up orphaned repair sessions (Cassandra 4.0+)

Essential for managing repairs in production environments.


List repair sessions.

Terminal window
nodetool repair_admin list [options]
OptionDescription
-a, --allInclude completed repairs, not just active
-st, --start-tokenStart token for filtering
-et, --end-tokenEnd token for filtering

Cancel a running repair.

Terminal window
nodetool repair_admin cancel -s <session_id> [-f]
OptionDescription
-s, --sessionSession ID to cancel (required)
-f, --forceForce cancellation

Clean up orphaned repair metadata.

Terminal window
nodetool repair_admin cleanup [-f] [keyspace] [tables...]
OptionDescription
-f, --forceForce cleanup
-st, --start-tokenStart token
-et, --end-tokenEnd token

Summarize pending repairs.

Terminal window
nodetool repair_admin summarize-pending

Summarize repaired ranges.

Terminal window
nodetool repair_admin summarize-repaired

Terminal window
nodetool repair_admin list

Output:

id state last activity coordinator participants participants_wp
a1b2c3d4-e5f6-7890-abcd-ef1234567890 RUNNING 2024-01-15T10:30:00Z 192.168.1.101 192.168.1.101,102 192.168.1.101,102
b2c3d4e5-f6a7-8901-bcde-f12345678901 RUNNING 2024-01-15T10:31:00Z 192.168.1.102 192.168.1.102,103 192.168.1.102,103
Terminal window
nodetool repair_admin list --all

Shows history of repairs including completed and failed.

Terminal window
nodetool repair_admin cancel -s a1b2c3d4-e5f6-7890-abcd-ef1234567890
Terminal window
nodetool repair_admin cleanup

FieldDescription
idUnique session identifier (UUID)
stateCurrent state (RUNNING, FAILED, COMPLETED)
commandRepair type (RANGE, VALIDATION, SYNC)
coordinatorNode coordinating the repair
participantsNodes involved in the repair
last_updateTimestamp of last status update
StateDescription
RUNNINGRepair is in progress
COMPLETEDRepair finished successfully
FAILEDRepair encountered an error

Before starting maintenance:

Terminal window
nodetool repair_admin list

Check if repairs are already running.

Terminal window
nodetool repair_admin list --all

View repair history to identify patterns.

When a repair is hung or needs to be stopped:

Terminal window
# Find the session ID
nodetool repair_admin list
# Cancel it
nodetool repair_admin cancel <session_id>

Ensure no repairs are running before:

  • Decommission
  • Adding nodes
  • Major maintenance
Terminal window
nodetool repair_admin list
# Should show no RUNNING repairs

Cancel Considerations

Cancel repairs when:

  • Repair is stuck (no progress)
  • Emergency maintenance needed
  • Repair started by mistake
  • Repair is impacting production too heavily
Terminal window
# Get session ID
nodetool repair_admin list
# Cancel the session
nodetool repair_admin cancel a1b2c3d4-e5f6-7890-abcd-ef1234567890

Canceled repairs leave data partially synchronized:

  1. Data already streamed remains in place
  2. Unprocessed ranges were not repaired
  3. Run repair again later to complete synchronization

id state command
a1b2c3d4-... RUNNING RANGE

Active repair - do not interfere unless necessary.

id state command
b2c3d4e5-... FAILED VALIDATION

Investigate Failures

Failed repairs indicate:

  • Node unreachable
  • Timeout occurred
  • Resource exhaustion
  • SSTable corruption

Check logs for details:

Terminal window
grep -i "repair.*failed\|repair.*error" /var/log/cassandra/system.log

Sessions that didn't clean up properly:

Terminal window
# Clean up orphaned metadata
nodetool repair_admin cleanup

Terminal window
# Check for existing repairs
nodetool repair_admin list
# Verify cluster health
nodetool status
Terminal window
# Watch progress
watch -n 30 'nodetool repair_admin list'
# Monitor streaming
nodetool netstats
Terminal window
# Verify completion
nodetool repair_admin list --all | grep COMPLETED
# Check for failures
nodetool repair_admin list --all | grep FAILED

If repair_admin list shows no sessions but repair seems running:

  • Check other nodes (repair coordinator may be different)
  • Check nodetool netstats for streaming activity

If cancel doesn't stop the repair:

  1. Verify correct session ID
  2. Try from the coordinator node
  3. Check logs for errors
  4. May need to wait for current streaming to complete

Unexpected repairs may be from:

  • Scheduled repair tools (AxonOps, Reaper)
  • Cron jobs
  • Application-triggered repairs

Check all potential sources.


AxonOps manages repairs automatically:

Terminal window
# View repairs including those managed by AxonOps
nodetool repair_admin list --all

Repairs started by AxonOps appear with distinctive session IDs.

If using Reaper for repair management:

  • Repairs appear in repair_admin list
  • Cancel through Reaper UI when possible
  • Use repair_admin cancel only if needed

#!/bin/bash
if nodetool repair_admin list | grep -q RUNNING; then
echo "Repairs are running"
exit 1
else
echo "No active repairs"
exit 0
fi
#!/bin/bash
# Emergency: cancel all running repairs
for session in $(nodetool repair_admin list | grep RUNNING | awk '{print $1}'); do
echo "Canceling $session"
nodetool repair_admin cancel "$session"
done
#!/bin/bash
while true; do
clear
echo "=== Repair Status $(date) ==="
nodetool repair_admin list
echo ""
echo "=== Network Activity ==="
nodetool netstats | head -20
sleep 30
done

CommandRelationship
repairStart repair operations
netstatsMonitor streaming during repair
statusCheck cluster state
tpstatsMonitor repair thread pools
compactionstatsValidation compactions during repair