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. This is caused by starting multiple conflicting incremental repairs at the same time. Conflicting anticompactions: ...

What it means

During the prepare phase of an incremental repair, Cassandra acquires SSTables for anticompaction. If the SSTables it needs intersect with SSTables already owned by another concurrent incremental repair session, the acquisition fails and this SSTableAcquisitionException is thrown, aborting the repair. Incremental repair requires exclusive SSTable ownership per session, so overlapping sessions are fundamentally conflicting.

Source

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

                                                   "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;
        }
    }

    public static class AcquisitionCallable implements Callable<AcquireResult>
    {
        private final ColumnFamilyStore cfs;
        private final TimeUUID sessionID;
        private final AntiCompactionPredicate predicate;
        private final int acquireRetrySeconds;
        private final int acquireSleepMillis;

        @VisibleForTesting
        public AcquisitionCallable(ColumnFamilyStore cfs, Collection<Range<Token>> ranges, TimeUUID sessionID, int acquireRetrySeconds, int acquireSleepMillis)
        {
            this(cfs, sessionID, acquireRetrySeconds, acquireSleepMillis, new AntiCompactionPredicate(ranges, sessionID));
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Ensure only one incremental repair runs at a time per table/token range (use repair scheduling tools like Reaper with locking).
Wait for the conflicting repair/anticompaction to finish, then retry the repair.
Serialize repair jobs via `nodetool tpstats`/`nodetool compactionstats` checks before starting a new incremental repair.
If incremental repair is not required, use full (pr -partitioner-range) repairs or subrange repairs on disjoint ranges.

Example fix

// before: two overlapping crons
0 2 * * * nodetool repair -inc myks mytable
0 2 * * * nodetool repair -inc myks mytable
// after: single serialized scheduler (e.g. Reaper) or staggered crons
0 2 * * * nodetool repair -inc myks mytable
0 2 * * * sleep 3600 && nodetool repair -inc otherks othertable

Defensive patterns

Strategy: validation

Validate before calling

if (CompactionManager.instance.getPendingTasks() > 0 || repairJobsInProgress(myks, mytable) > 0) { throw new IllegalStateException("another incremental repair in progress"); }

Try / catch

try { nodetool-repair-inc } catch (SSTableAcquisitionException e) { waitForConflictingRepair(); retryWithBackoff(); }

Prevention

Use a single repair coordinator (e.g. Reaper) with job locking
Serialize incremental repairs per table/range in cron schedules
Monitor compactionstats for active anticompactions before starting repairs

When it happens

Trigger: Running `nodetool repair --incremental` on the same table from two clients/nodes at overlapping times; a scheduled repair job overlapping a manually triggered one; a previous repair session's anticompaction still in progress when a new incremental repair starts.

Common situations: Cron-based repair schedules overlapping with ad-hoc repairs; monitoring systems re-triggering repairs because a prior one appeared stuck; multi-DC repairs started at similar times on the same token ranges.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

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