What causes "Invalid SSTable %s, please force %srepair" in apache/cassandra?

Run nodetool repair (or a full repair if mutateRepairStatus was used) to restore data from replicas, then re-verify

apache/cassandra · critical · CorruptSSTableException

Invalid SSTable %s, please force %srepair

Error message

Invalid SSTable %s, please force %srepair

What it means

SortedTableVerifier.markAndThrow() builds an exception reporting that SSTable verification failed, telling the operator to run either a regular repair or a full repair (depending on mutateRepaired/mutateRepairStatus options). If invokeDiskFailurePolicy is set it escalates to CorruptSSTableException (triggering disk-failure policy), otherwise a plain RuntimeException wrapping the underlying cause.

Source

Thrown at src/java/org/apache/cassandra/io/sstable/format/SortedTableVerifier.java:142

    }

    protected void markAndThrow(Throwable cause, boolean mutateRepaired)
    {
        if (mutateRepaired && options.mutateRepairStatus) // if we are able to mutate repaired flag, an incremental repair should be enough
        {
            try
            {
                sstable.mutateRepairedAndReload(ActiveRepairService.UNREPAIRED_SSTABLE, sstable.getPendingRepair(), sstable.isTransient());
                cfs.getTracker().notifySSTableRepairedStatusChanged(Collections.singleton(sstable));
            }
            catch (IOException ioe)
            {
                outputHandler.output("Error mutating repairedAt for SSTable %s, as part of markAndThrow", sstable.getFilename());
            }
        }
        Exception e = new Exception(String.format("Invalid SSTable %s, please force %srepair", sstable.getFilename(), (mutateRepaired && options.mutateRepairStatus) ? "" : "a full "), cause);
        if (options.invokeDiskFailurePolicy)
            throw new CorruptSSTableException(e, sstable.getFilename());
        else
            throw new RuntimeException(e);
    }

    public void verify()
    {
        verifySSTableVersion();

        verifySSTableMetadata();

        verifyIndex();

        verifyBloomFilter();

        // TODO: when making it possible to clean up system_cluster_metadata, we should make sure that non-cms members don't have any sstables there
        if (options.checkOwnsTokens && !isOffline && !(cfs.getPartitioner() instanceof LocalPartitioner) && !(cfs.getPartitioner() == MetaStrategy.partitioner))
        {
            if (verifyOwnedRanges() == 0)

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Run nodetool repair (or a full repair if mutateRepairStatus was used) to restore data from replicas, then re-verify
Run nodetool scrub to move corrupted rows out and quarantine the bad SSTable
Replace the failing disk / check hardware (SMART, dmesg) since corruption is often physical
Remove the corrupted SSTable after confirming replica coverage via repair

Example fix

# before: ignoring verify failures
nodetool verify ks tbl || true
# after: verify, then repair and re-verify
nodetool verify ks tbl || (nodetool repair -full ks tbl && nodetool verify ks tbl)

Defensive patterns

Strategy: try-catch

Validate before calling

// run verification proactively before mark/reliance
nodetool verify ks tbl
// or programmatically:
new SortedTableVerifier(cfs, sstable, options, handler, false).verify();

Try / catch

try { verifier.verify(); }
catch (RuntimeException e) {
    if (e.getMessage().contains("please force") && e.getMessage().contains("repair")) {
        logger.error("Corrupt sstable detected: {}", e.getCause());
        runRepair(keyspace, table, /*full=*/ true);
    } else throw e;
}

Prevention

Schedule regular nodetool verify across all tables
Verify after any suspicion of disk issues or power loss
Run repairs on schedule so corrupt data can be restored from replicas
Monitor disk SMART metrics and replace degrading hardware early

When it happens

Trigger: Running nodetool verify / sstable verify when the SSTable fails integrity checks (checksums, index consistency, key order) via verifySSTableMetadata or markAndThrow recursion — indicating detected corruption in the data/index components.

Common situations: Bit rot or failing disks corrupting SSTables; post-power-loss corruption detection; routine verification sweeps finding files damaged months earlier; verifying after suspicious node behavior.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

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