Prepare phase for incremental repair session %s was unable t

Error message

Prepare phase for incremental repair session %s was unable to acquire exclusive access to the neccesary sstables. This is usually caused by running multiple incremental repairs on nodes that share token ranges

What it means

During the prepare phase of an incremental repair, PendingAntiCompaction must acquire exclusive access to the sstables being repaired so their contents cannot change mid-repair. If acquisition fails for any of the requested ranges after retries, it logs a warning and fails the prepare step with SSTableAcquisitionException, which aborts the repair session.

Source

Thrown at src/java/org/apache/cassandra/db/repair/PendingAntiCompaction.java:313

        public Future<List<Void>> apply(List<AcquireResult> results)
        {
            if (Iterables.any(results, AcquisitionCallback::shouldAbort))
            {
                // Release all sstables, and report failure back to coordinator
                for (AcquireResult result : results)
                {
                    if (result != null)
                    {
                        logger.info("Releasing acquired sstables for {}.{}", result.cfs.metadata.keyspace, result.cfs.metadata.name);
                        result.abort();
                    }
                }
                String message = String.format("Prepare phase for incremental repair session %s was unable to " +
                                               "acquire exclusive access to the neccesary sstables. " +
                                               "This is usually caused by running multiple incremental repairs on nodes that share token ranges",
                                               parentRepairSession);
                logger.warn(message);
                return ImmediateFuture.failure(new SSTableAcquisitionException(message));
            }
            else
            {
                List<Future<Void>> pendingAntiCompactions = new ArrayList<>(results.size());
                for (AcquireResult result : results)
                {
                    if (result.txn != null)
                    {
                        Future<Void> future = submitPendingAntiCompaction(result);
                        pendingAntiCompactions.add(future);
                    }
                }

                return FutureCombiner.allOf(pendingAntiCompactions);
            }
        }
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Stop overlapping repair sessions (nodetool repair_admin cancel / list) and ensure only one incremental repair touches a shared range at a time
Serialize repairs that share token ranges, or partition them so ranges do not overlap per node
Retry the repair once the competing session has finished and sstables are released
Check for stale/leaked repair sessions after node restarts and clear them before restarting repairs

Example fix

// before: concurrent overlapping repairs
nodetool repair -inc keyspace1 &
nodetool repair -inc keyspace1 &
// after: serialized repairs
nodetool repair -inc keyspace1 && nodetool repair -inc keyspace2

Defensive patterns

Strategy: retry

Validate before calling

// check for active repair sessions before starting another
// nodetool repair_admin list  -> must be empty
// verify no overlapping ranges: confirm token range partitioning of concurrent repairs

Prevention

Serialize repair sessions; never run two incremental repairs over the same range on a node
Use repair_admin tooling to detect and clean stale sessions
Automate repairs via a scheduler that enforces single-session-per-range
After node restarts, verify no leaked sessions remain before repairing

When it happens

Trigger: apply() runs acquisition tasks for each range; any AcquireResult is a failure, most commonly because another incremental repair already holds exclusive access to the same sstables via anti-compaction.

Common situations: Running two incremental repairs in parallel that cover overlapping token ranges on the same node; a previous repair session that did not fully clean up; scripted repair automation kicking off repairs while a prior one is still running.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/86b6fa1dd00e313f. Report an issue: GitHub.