apache/cassandra · critical · CorruptSSTableException

SSTable first key %s > last key %s

Error message

SSTable first key %s > last key %s

What it means

SSTableReader.validate() is called when a reader is built and asserts that the SSTable's first decorated key sorts before (or equals) its last key and that the token bounds exist. A violation means the SSTable's index/stats metadata is internally inconsistent, so Cassandra wraps it in a CorruptSSTableException.

Source

Thrown at src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java:696

        }
    }

    /**
     * This method is expected to close the components which occupy memory but are not needed when we just want to
     * stream the components (for example, when SSTable is opened with SSTableLoader). The method should call
     * {@link #closeInternalComponent(AutoCloseable)} for each such component. Leaving the implementation empty is
     * valid given there are not such resources to release.
     */
    public abstract void releaseInMemoryComponents();

    /**
     * Perform any validation needed for the reader upon creation before returning it from the {@link Builder}.
     */
    public void validate()
    {
        if (this.first.compareTo(this.last) > 0 || bounds == null)
        {
            throw new CorruptSSTableException(new IllegalStateException(String.format("SSTable first key %s > last key %s", this.first, this.last)), getFilename());
        }
    }

    /**
     * Returns the compression metadata for this sstable. Note that the compression metdata is a resource and should not
     * be closed by the caller.
     * TODO do not return a closeable resource or return a shared copy
     *
     * @throws IllegalStateException if the sstable is not compressed
     */
    public CompressionMetadata getCompressionMetadata()
    {
        if (!compression)
            throw new IllegalStateException(this + " is not compressed");

        return dfile.compressionMetadata().get();
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Run nodetool scrub on the affected keyspace/table to move bad data out or drop corrupted SSTables
  2. Run nodetool repair (and sstableverify) after scrub to restore replication consistency
  3. Restore the corrupted SSTable from a backup/snapshot if available
  4. If the SSTable came from an external source, re-generate or re-load it correctly (proper sstableloader usage)

Example fix

// before: blindly copying sstables between nodes
cp /var/lib/cassandra/data/ks/tbl-*/xx-Data.db /other/node/
// after: use sstableloader
sstableloader -d other.node /var/lib/cassandra/data/ks/tbl/
Defensive patterns

Strategy: validation

Validate before calling

// pre-open sanity: verify components
sstableverify -- ks tbl   // or: nodetool verify ks tbl
sstablemetadata <path>/xx-big-Statistics.db  // check first/last tokens

Try / catch

try { SSTableReader.open(descriptor, components, metadata); }
catch (CorruptSSTableException e) {
    logger.error("SSTable {} has invalid first/last key metadata", descriptor, e);
    scheduleScrubAndRepair(keyspace, table);
}

Prevention

When it happens

Trigger: Opening an SSTable whose Statistics.db / Summary component reports first key > last key — e.g. a truncated, partially-written, or hand-edited SSTable, or a corrupted -Statistics.db during startup, compaction, or validation when building the reader.

Common situations: Hardware failures or unclean shutdown corrupting SSTable components; manually copying SSTables between nodes; aborted/interfered compactions leaving inconsistent metadata; tampering with SSTable files.

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/f2b3325988f4fdf8. Report an issue: GitHub.