nodetool repair_admin
Manages and monitors repair sessions on the cluster.
Synopsis
Section titled “Synopsis”nodetool [connection_options] repair_admin <list | cancel | cleanup | summarize-pending | summarize-repaired> [options]See connection options for connection options.
Description
Section titled “Description”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.
Subcommands
Section titled “Subcommands”List repair sessions.
nodetool repair_admin list [options]| Option | Description |
|---|---|
-a, --all | Include completed repairs, not just active |
-st, --start-token | Start token for filtering |
-et, --end-token | End token for filtering |
cancel
Section titled “cancel”Cancel a running repair.
nodetool repair_admin cancel -s <session_id> [-f]| Option | Description |
|---|---|
-s, --session | Session ID to cancel (required) |
-f, --force | Force cancellation |
cleanup (4.0+)
Section titled “cleanup (4.0+)”Clean up orphaned repair metadata.
nodetool repair_admin cleanup [-f] [keyspace] [tables...]| Option | Description |
|---|---|
-f, --force | Force cleanup |
-st, --start-token | Start token |
-et, --end-token | End token |
summarize-pending
Section titled “summarize-pending”Summarize pending repairs.
nodetool repair_admin summarize-pendingsummarize-repaired
Section titled “summarize-repaired”Summarize repaired ranges.
nodetool repair_admin summarize-repairedExamples
Section titled “Examples”List Active Repairs
Section titled “List Active Repairs”nodetool repair_admin listOutput:
id state last activity coordinator participants participants_wpa1b2c3d4-e5f6-7890-abcd-ef1234567890 RUNNING 2024-01-15T10:30:00Z 192.168.1.101 192.168.1.101,102 192.168.1.101,102b2c3d4e5-f6a7-8901-bcde-f12345678901 RUNNING 2024-01-15T10:31:00Z 192.168.1.102 192.168.1.102,103 192.168.1.102,103List All Repairs (Including Completed)
Section titled “List All Repairs (Including Completed)”nodetool repair_admin list --allShows history of repairs including completed and failed.
Cancel a Repair
Section titled “Cancel a Repair”nodetool repair_admin cancel -s a1b2c3d4-e5f6-7890-abcd-ef1234567890Clean Up Orphaned Sessions (4.0+)
Section titled “Clean Up Orphaned Sessions (4.0+)”nodetool repair_admin cleanupOutput Fields
Section titled “Output Fields”Repair Session Information
Section titled “Repair Session Information”| Field | Description |
|---|---|
| id | Unique session identifier (UUID) |
| state | Current state (RUNNING, FAILED, COMPLETED) |
| command | Repair type (RANGE, VALIDATION, SYNC) |
| coordinator | Node coordinating the repair |
| participants | Nodes involved in the repair |
| last_update | Timestamp of last status update |
Session States
Section titled “Session States”| State | Description |
|---|---|
| RUNNING | Repair is in progress |
| COMPLETED | Repair finished successfully |
| FAILED | Repair encountered an error |
When to Use
Section titled “When to Use”Monitor Active Repairs
Section titled “Monitor Active Repairs”Before starting maintenance:
nodetool repair_admin listCheck if repairs are already running.
Diagnose Slow Repairs
Section titled “Diagnose Slow Repairs”nodetool repair_admin list --allView repair history to identify patterns.
Cancel Stuck Repairs
Section titled “Cancel Stuck Repairs”When a repair is hung or needs to be stopped:
# Find the session IDnodetool repair_admin list
# Cancel itnodetool repair_admin cancel <session_id>Before Topology Changes
Section titled “Before Topology Changes”Ensure no repairs are running before:
- Decommission
- Adding nodes
- Major maintenance
nodetool repair_admin list# Should show no RUNNING repairsCanceling Repairs
Section titled “Canceling Repairs”When to Cancel
Section titled “When to Cancel”Cancel Considerations
Cancel repairs when:
- Repair is stuck (no progress)
- Emergency maintenance needed
- Repair started by mistake
- Repair is impacting production too heavily
How to Cancel
Section titled “How to Cancel”# Get session IDnodetool repair_admin list
# Cancel the sessionnodetool repair_admin cancel a1b2c3d4-e5f6-7890-abcd-ef1234567890After Canceling
Section titled “After Canceling”Canceled repairs leave data partially synchronized:
- Data already streamed remains in place
- Unprocessed ranges were not repaired
- Run repair again later to complete synchronization
Repair States Deep Dive
Section titled “Repair States Deep Dive”Running Repair
Section titled “Running Repair”id state commanda1b2c3d4-... RUNNING RANGEActive repair - do not interfere unless necessary.
Failed Repair
Section titled “Failed Repair”id state commandb2c3d4e5-... FAILED VALIDATIONInvestigate Failures
Failed repairs indicate:
- Node unreachable
- Timeout occurred
- Resource exhaustion
- SSTable corruption
Check logs for details:
grep -i "repair.*failed\|repair.*error" /var/log/cassandra/system.logOrphaned Sessions
Section titled “Orphaned Sessions”Sessions that didn't clean up properly:
# Clean up orphaned metadatanodetool repair_admin cleanupMonitoring Best Practices
Section titled “Monitoring Best Practices”Before Starting Repair
Section titled “Before Starting Repair”# Check for existing repairsnodetool repair_admin list
# Verify cluster healthnodetool statusDuring Repair
Section titled “During Repair”# Watch progresswatch -n 30 'nodetool repair_admin list'
# Monitor streamingnodetool netstatsAfter Repair
Section titled “After Repair”# Verify completionnodetool repair_admin list --all | grep COMPLETED
# Check for failuresnodetool repair_admin list --all | grep FAILEDCommon Issues
Section titled “Common Issues”Cannot Find Session ID
Section titled “Cannot Find Session ID”If repair_admin list shows no sessions but repair seems running:
- Check other nodes (repair coordinator may be different)
- Check
nodetool netstatsfor streaming activity
Cancel Doesn't Work
Section titled “Cancel Doesn't Work”If cancel doesn't stop the repair:
- Verify correct session ID
- Try from the coordinator node
- Check logs for errors
- May need to wait for current streaming to complete
Repairs Start Automatically
Section titled “Repairs Start Automatically”Unexpected repairs may be from:
- Scheduled repair tools (AxonOps, Reaper)
- Cron jobs
- Application-triggered repairs
Check all potential sources.
Integration with Repair Tools
Section titled “Integration with Repair Tools”AxonOps
Section titled “AxonOps”AxonOps manages repairs automatically:
# View repairs including those managed by AxonOpsnodetool repair_admin list --allRepairs started by AxonOps appear with distinctive session IDs.
Cassandra Reaper
Section titled “Cassandra Reaper”If using Reaper for repair management:
- Repairs appear in
repair_admin list - Cancel through Reaper UI when possible
- Use
repair_admin cancelonly if needed
Scripting Examples
Section titled “Scripting Examples”Check for Active Repairs
Section titled “Check for Active Repairs”#!/bin/bashif nodetool repair_admin list | grep -q RUNNING; then echo "Repairs are running" exit 1else echo "No active repairs" exit 0fiCancel All Repairs
Section titled “Cancel All Repairs”#!/bin/bash# Emergency: cancel all running repairsfor session in $(nodetool repair_admin list | grep RUNNING | awk '{print $1}'); do echo "Canceling $session" nodetool repair_admin cancel "$session"doneMonitor Repair Progress
Section titled “Monitor Repair Progress”#!/bin/bashwhile true; do clear echo "=== Repair Status $(date) ===" nodetool repair_admin list echo "" echo "=== Network Activity ===" nodetool netstats | head -20 sleep 30doneRelated Commands
Section titled “Related Commands”| Command | Relationship |
|---|---|
| repair | Start repair operations |
| netstats | Monitor streaming during repair |
| status | Check cluster state |
| tpstats | Monitor repair thread pools |
| compactionstats | Validation compactions during repair |