apache/cassandra · critical · CorruptSSTableException

Invalid key order: current

Error message

Invalid key order: current %s <= previous %s

What it means

While iterating partitions in key order, SSTableSimpleScanner.next() checks that each newly read partition key sorts strictly after the previous one. If currentKey <= lastKey, the SSTable is not in valid sorted order, so the reader is marked suspect and a CorruptSSTableException is thrown naming both keys.

Solutions

1. Run nodetool scrub on the table to isolate/discard the corrupt SSTable
2. Run sstableverify / nodetool verify to identify all corrupted files
3. Replace the bad SSTable by running nodetool repair so other replicas restore the data
4. Remove the suspect SSTable from external scanning; re-generate it via compaction or streaming from a healthy replica

Example fix

// before: directly scanning suspect sstable
SSTableSimpleScanner sc = new SSTableSimpleScanner(sstable, ranges);
// after: verify first
VerifierOptions opts = new VerifierOptions.Builder().build();
new SortedTableVerifier(cfs, sstable, opts, new NoopOutputHandler(), false).verify();
SSTableSimpleScanner sc = new SSTableSimpleScanner(sstable, ranges);

// verify integrity before scanning
new SortedTableVerifier(cfs, sstable, verifierOptions, outputHandler, false).verify();

try { iterate(scanner); }
catch (CorruptSSTableException e) {
    if (e.getMessage().startsWith("Invalid key order")) {
        sstable.markSuspect();
        logger.error("SSTable {} out of key order, scheduling scrub", sstable.getFilename(), e);
        scheduleScrubAndRepair();
    } else throw e;
}

When it happens

Trigger: Scanning an SSTable whose Data.db partition order violates the sort order guaranteed by the storage engine — caused by data corruption, truncation, or files written by broken/external tooling; detected during next() as the scanner walks partitions sequentially.

Common situations: Hardware corruption or bad disks altering SSTable contents; SSTables produced/modified by third-party tools; incomplete writes from crashed compactions being scanned directly.

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

• Can't import sstable
• Cannot deserialize index summary from
• Checksums do not match for
• Clustering block upper bits (those not associated with…
• Corrupt clustering value length

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

Appendix: source

Thrown at src/java/org/apache/cassandra/io/sstable/format/SSTableSimpleScanner.java:218

            }
            else
            {
                throw e;
            }
        }
    }

    public UnfilteredRowIterator next()
    {
        if (!hasNext())
            throw new NoSuchElementException();

        currentIterator = SSTableIdentityIterator.create(sstable, tableMetadata, dfile, false);
        DecoratedKey currentKey = currentIterator.partitionKey();
        if (lastKey != null && lastKey.compareTo(currentKey) >= 0)
        {
            sstable.markSuspect();
            throw new CorruptSSTableException(new IllegalStateException(String.format("Invalid key order: current %s <= previous %s",
                                                                                      currentKey,
                                                                                      lastKey)),
                                              sstable.getFilename());
        }
        lastKey = currentKey;
        return currentIterator;
    }

    public void remove()
    {
        throw new UnsupportedOperationException();
    }

    @Override
    public String toString()
    {
        return String.format("%s(sstable=%s)", getClass().getSimpleName(), sstable);
    }

View on GitHub (pinned to 88fd0f6a0e)