nodetool verify

Verifies SSTable integrity without modifying data.

Synopsis

nodetool [connection_options] verify [options] [--] [keyspace [table ...]]

See connection options for connection options.

Description

nodetool verify performs a non-destructive check of SSTable integrity. Unlike scrub, verify only reads and validates—it never modifies data. Use verify to detect corruption before deciding whether to run scrub.

Force Flag Required

By default, the command exits with an error unless the -f/--force flag is provided. This is a safety mechanism to ensure operators understand the I/O impact of verification.

How Verification Works

The verify command performs integrity checks by reading SSTable files and validating their internal consistency:

Checksum Validation - Each SSTable has an associated digest file (*-Digest.crc32) containing a checksum of the entire Data.db file. Verify reads the data file, computes a fresh checksum, and compares it against the stored digest. A mismatch indicates data corruption from disk errors, incomplete writes, or bit rot.
Partition Key Ordering - SSTables store partitions in sorted token order. Verify confirms that partition keys appear in strictly ascending token order. Out-of-order keys indicate structural corruption.
Clustering Column Ordering - Within each partition, rows must be sorted by clustering columns. Verify validates this ordering to detect intra-partition corruption.
Index Consistency - The SSTable index (*-Index.db) contains offsets to partition locations in the data file. Verify confirms that index entries point to valid partition boundaries and that all partitions are indexed.
Bloom Filter Validation - Checks that the Bloom filter file (*-Filter.db) is readable and structurally valid.
Compression Metadata - For compressed SSTables, validates the compression offset map (*-CompressionInfo.db) which maps logical offsets to compressed chunk locations.

Checksum Architecture

Cassandra uses different checksum mechanisms depending on whether SSTables are compressed:

SSTable Type	Checksum File	Checksum Scope	Read-Time Verification
Uncompressed	`*-Digest.crc32`	Entire Data.db file	Per-file during verify
Compressed	`-Digest.crc32` + `-CompressionInfo.db`	Entire file + per-chunk metadata	Per-chunk during reads

Compression and Data Integrity

Compressed SSTables (the default) provide per-chunk verification during normal reads, controlled by the crc_check_chance table option (default 1.0 = 100%). This is Cassandra's primary defense against bit rot. The nodetool verify command performs a complete scan regardless of this setting.

Arguments

Argument	Description
`keyspace`	Keyspace to verify. If omitted, verifies all keyspaces
`table`	Specific table(s) to verify

Options

Option	Description
`-f, --force`	Required. Force verification to proceed
`-e, --extended-verify`	Extended verification (checks all components)
`-c, --check-version`	Check SSTable version compatibility
`-d, --dfp`	Invoke disk failure policy on failure
`-r, --rsc`	Mutate repairedAt, pendingRepair, and repairedSessionColumn
`-t, --check-tokens`	Verify tokens are within node's ranges (requires `-e`)
`-q, --quick`	Quick check (fewer validations)
`-s, --sai-only`	Verify only Storage-Attached Indexes (SAI)
`-i, --include-sai`	Include SAI verification along with SSTable verification

Option Dependencies

The --check-tokens option requires --extended-verify to be specified.

What Verify Checks

Standard Verification

Partition key ordering
Clustering column ordering
SSTable file checksums
Index consistency
Bloom filter validity

Extended Verification (`-e/--extended-verify`)

All data component files
Compression metadata
Statistics file integrity
Summary file consistency
TOC file completeness
Token range validation (when -t also specified)

Examples

Verify Specific Table

nodetool verify -f my_keyspace my_table

Verify All Tables in Keyspace

nodetool verify -f my_keyspace

Extended Verification

nodetool verify -f -e my_keyspace my_table

Quick Verification

nodetool verify -f -q my_keyspace

Verify with Token Range Check

# Note: -t requires -e (extended-verify)
nodetool verify -f -e -t my_keyspace my_table

Verify SAI Indexes Only

nodetool verify -f -s my_keyspace my_table

Include SAI in Verification

nodetool verify -f -i my_keyspace my_table

Output

No Corruption Found

Completed verification of my_keyspace.my_table

Corruption Detected

ERROR: Corrupted SSTable: /var/lib/cassandra/data/my_keyspace/my_table-abc123/nb-1-big-Data.db
  - Invalid partition key at position 12345
  - Checksum mismatch in Data.db

When to Use

Proactive Health Checks

# Regular integrity check (e.g., weekly)
nodetool verify -f my_keyspace

After Disk Errors

# After seeing I/O errors in logs
nodetool verify -f

Before Maintenance

# Verify before backup
nodetool verify -f my_keyspace
nodetool snapshot -t pre_backup my_keyspace

After Unexpected Shutdown

# After crash or power loss
nodetool verify -f

Verify vs. Scrub Decision Flow

Verify Result	Action
No errors	No action needed
Errors found	Run `nodetool scrub` to fix
Scrub fails	Run `nodetool scrub -s` (skips corrupted)
After scrub -s	Run `nodetool repair` to recover data

Performance Impact

Read-Only Operation

Verify is read-only but still I/O intensive:

Reads all SSTable data files
Computes checksums
No writes or modifications
Lower impact than scrub

Estimated Duration

Table Size	Approximate Time
10 GB	5-15 minutes
100 GB	30-90 minutes
1 TB	5-10 hours

Automation

Scheduled Verification Script

#!/bin/bash
# verify_all.sh - Weekly verification

LOG="/var/log/cassandra/verify_$(date +%Y%m%d).log"

echo "Starting verification at $(date)" >> $LOG

for ks in $(nodetool tablestats | grep "Keyspace:" | awk '{print $2}'); do
    echo "Verifying $ks..." >> $LOG
    nodetool verify -f $ks >> $LOG 2>&1
done

echo "Completed at $(date)" >> $LOG

# Alert on errors
if grep -q "ERROR" $LOG; then
    echo "Verification errors found - check $LOG"
fi

Common Issues

"Not enough space"

Verify needs memory for checksums:

# Run on one table at a time
nodetool verify -f my_keyspace table1
nodetool verify -f my_keyspace table2

Verification Takes Too Long

# Use quick mode for faster check
nodetool verify -f -q my_keyspace

# Or verify specific tables only
nodetool verify -f my_keyspace critical_table

Best Practices

Verification Guidelines

Run regularly - Weekly or after incidents
Check before backup - Ensure clean backups
Use extended mode periodically - Thorough check
Monitor duration - Baseline normal verification time
Act on findings - Follow up with scrub if needed

Command	Relationship
scrub	Fix corruption found by verify
repair	Recover data after scrub with skip
tablestats	Check table health metrics
snapshot	Backup after successful verify