apache/cassandra · error · SSTableAcquisitionException

Prepare phase failed because it encountered legacy sstables

Error message

Prepare phase failed because it encountered legacy sstables that don't support pending repair, run upgradesstables before starting incremental repairs, repair session (%s)

What it means

Incremental repair requires all sstables to support pending-repair metadata (sstable format 'mc' and later). During PendingAntiCompaction's prepare phase, if an intersecting sstable was written by an older sstable format lacking pending repair support, it throws SSTableAcquisitionException with this message, telling the operator to run upgradesstables first.

Source

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

        }

        public boolean apply(SSTableReader sstable)
        {
            if (!sstable.intersects(ranges))
                return false;

            StatsMetadata metadata = sstable.getSSTableMetadata();

            // exclude repaired sstables
            if (metadata.repairedAt != UNREPAIRED_SSTABLE)
                return false;

            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())

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Run 'nodetool upgradesstables' on the affected keyspace/table (or entire cluster) so all sstables use the current format
2. Verify sstable versions with 'nodetool tablestats' / sstablemetadata and confirm no pre-mc files remain
3. Re-run the incremental repair after the upgrade completes
4. Prevent recurrence by running upgradesstables as a standard post-upgrade step

Example fix

// before
nodetool repair -inc my_keyspace
// after
nodetool upgradesstables my_keyspace
nodetool repair -inc my_keyspace

// shell: detect legacy sstables before incremental repair
nodetool tablestats -- keyspace.table | grep -i 'sstable' # then verify versions via sstablemetadata

try { repairService.submitIncremental(); } catch (Exception e) { if (e.getMessage().contains("legacy sstables")) { runUpgradeSstables(); retry(); } else throw e; }

When it happens

Trigger: Running nodetool repair with incremental repair enabled on a table containing sstables written by a pre-3.0 sstable format (e.g. after upgrading from Cassandra 2.x without upgradesstables); newly streamed/compacted legacy files untouched since upgrade.

Common situations: Post-upgrade environments where upgradesstables was skipped; restoring old backups onto upgraded nodes; nodes with long-lived legacy sstables never rewritten.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Could not reference sstables
• Prepare phase for incremental repair session %s has failed b
• Unable to cancel in-progress compactions for {keyspace}.{tab
• SSTable %s is marked pending for non-finalized incremental r
• An incremental repair with session id {id} finished during t

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