apache/cassandra · critical · CorruptSSTableException

Checksums do not match for

Error message

Checksums do not match for 

What it means

Thrown by MetadataSerializer.maybeValidateChecksum when the CRC32 stored at the end of the Stats component does not match the checksum computed over the statistics metadata just read. Wrapped in a CorruptSSTableException naming the file, it prevents Cassandra from trusting corrupted table statistics.

Source

Thrown at src/java/org/apache/cassandra/io/sstable/metadata/MetadataSerializer.java:226

                components.put(type, type.serializer.deserialize(descriptor.version, dataInputBuffer));
            }
        }

        return components;
    }

    private static void maybeValidateChecksum(CRC32 crc, FileDataInput in, Descriptor descriptor) throws IOException
    {
        if (!descriptor.version.hasMetadataChecksum())
            return;

        int actualChecksum = (int) crc.getValue();
        int expectedChecksum = in.readInt();

        if (actualChecksum != expectedChecksum)
        {
            File file = descriptor.fileFor(Components.STATS);
            throw new CorruptSSTableException(new IOException("Checksums do not match for " + file), file);
        }
    }

    @Override
    public void mutate(Descriptor descriptor, String description, UnaryOperator<StatsMetadata> transform) throws IOException
    {
        if (logger.isTraceEnabled())
            logger.trace("Mutating {} to {}", descriptor.fileFor(Components.STATS), description);

        mutate(descriptor, transform);
    }

    @Override
    public void mutateLevel(Descriptor descriptor, int newLevel) throws IOException
    {
        if (logger.isTraceEnabled())
            logger.trace("Mutating {} to level {}", descriptor.fileFor(Components.STATS), newLevel);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Restore the matching Statistics.db from snapshot/backup of the same sstable generation
2. Remove the corrupt sstable and run `nodetool repair` to re-stream from replicas
3. Check storage health (SMART, filesystem errors) for the underlying disk
4. Use `sstablemetadata` on the file to confirm which component is corrupt before deleting

// pre-validate stats component before opening sstable
try (var in = new RandomAccessReader(statsFile)) { /* recompute CRC and compare to trailing int */ }

try { metadata = serializer.deserialize(descriptor, ...); } catch (CorruptSSTableException e) { logger.error("corrupt stats for {}", e.getFile(), e); quarantineOrRepair(descriptor); }

When it happens

Trigger: Reading sstable stats metadata (during sstable open, compaction, or sstablemetadata tool) where the trailing checksum in Statistics.db does not match the computed value — bytes were altered, truncated, or the file is from a mismatched generation.

Common situations: Disk corruption, partially copied/incomplete sstable restores, mixing sstable components from different generations, faulty hardware or network storage.

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

• Corrupted file: integrity check (%s) failed for %s: %d != %d
• Corrupt flags value for clustering prefix (isStatic flag set
• Corrupted sstable. Invalid flags found deserializing Deletio
• Failed to import sstable <filename>
• Checksum didn't match (expected: %d, actual: %d)

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