apache/cassandra · error · SSTableAcquisitionException
Prepare phase for incremental repair session %s has failed b
Error message
Prepare phase for incremental repair session %s has failed because it encountered intersecting sstables belonging to another incremental repair session (%s). This is caused by starting an incremental repair session before a previous one has completed. Check nodetool repair_admin for hung sessions and fix them.
What it means
Incremental repair requires that sstables intersecting the repair range belong to no other unfinished repair session. When the prepare phase finds an intersecting sstable whose pendingRepair id belongs to another session that is not finalized, it throws SSTableAcquisitionException with this message indicating an overlapping incremental repair was started before the previous one completed.
Source
Thrown at src/java/org/apache/cassandra/db/repair/PendingAntiCompaction.java:146
if (!sstable.descriptor.version.hasPendingRepair())
{
String message = String.format("Prepare phase failed because it encountered legacy sstables that don't " +
"support pending repair, run upgradesstables before starting incremental " +
"repairs, repair session (%s)", prsid);
throw new SSTableAcquisitionException(message);
}
// exclude sstables pending repair, but record session ids for
// non-finalized sessions for a later error message
if (metadata.pendingRepair != NO_PENDING_REPAIR)
{
if (!ActiveRepairService.instance().consistent.local.isSessionFinalized(metadata.pendingRepair))
{
String message = String.format("Prepare phase for incremental repair session %s has failed because it encountered " +
"intersecting sstables belonging to another incremental repair session (%s). This is " +
"caused by starting an incremental repair session before a previous one has completed. " +
"Check nodetool repair_admin for hung sessions and fix them.", prsid, metadata.pendingRepair);
throw new SSTableAcquisitionException(message);
}
return false;
}
Collection<CompactionInfo> cis = CompactionManager.instance.active.getCompactionsForSSTable(sstable, OperationType.ANTICOMPACTION);
if (cis != null && !cis.isEmpty())
{
// todo: start tracking the parent repair session id that created the anticompaction to be able to give a better error messsage here:
StringBuilder sb = new StringBuilder();
sb.append("Prepare phase for incremental repair session ");
sb.append(prsid);
sb.append(" has failed because it encountered intersecting sstables belonging to another incremental repair session. ");
sb.append("This is caused by starting multiple conflicting incremental repairs at the same time. ");
sb.append("Conflicting anticompactions: ");
for (CompactionInfo ci : cis)
sb.append(ci.getTaskId() == null ? "no compaction id" : ci.getTaskId()).append(':').append(ci.getSSTables()).append(',');
throw new SSTableAcquisitionException(sb.toString());
}
return true;View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Run 'nodetool repair_admin list' to find hung sessions and 'nodetool repair_admin cleanup' (fail the sessions) for stale ones
- Wait for the current incremental repair to complete before starting another on overlapping ranges
- Fix scheduling so incremental repairs over the same ranges never overlap
- After cleanup, re-run the repair; consider full (non-incremental) repair to reset pendingRepair state if sessions are badly stuck
Example fix
// before nodetool repair -inc ks # previous session still hung // after nodetool repair_admin list nodetool repair_admin cleanup --force nodetool repair -inc ks
Defensive patterns
Strategy: validation
Validate before calling
// shell: check for un-finalized sessions before starting repair nodetool repair_admin list
Try / catch
try { repairService.submitIncremental(); } catch (Exception e) { if (e.getMessage().contains("another incremental repair session")) { cleanupHungSessions(); retry(); } else throw e; } Prevention
- Never overlap incremental repairs on the same ranges
- Alert on repair sessions that exceed expected duration
- Use repair_admin to clean up sessions after node failures
When it happens
Trigger: Starting a new incremental repair on a token range while a previous incremental repair session over the same range is still running or hung (never finalized); crashed repair sessions leaving sstables with dangling pendingRepair ids.
Common situations: Overlapping scheduled repairs (e.g. cron firing while a manual repair runs); hung repair sessions after node restarts/failures; repair timeouts leaving unfinalized sessions.
Related errors
- Prepare phase failed because it encountered legacy sstables
- An incremental repair with session id {id} finished during t
- Incremental repair session %s has failed
- Properties '%s' and '%s' are mutually exclusive
- repair_session_max_tree_depth should not be < 10, but was ${
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/54999dd4543faa0b.
Report an issue: GitHub.