The CHECK TABLE command recalculates and compares checksums for each data part, revealing corruption or inconsistencies in MergeTree-family tables.
Hard-disk errors, incomplete replications, or manual file moves can corrupt a table’s data parts. Running CHECK TABLE
quickly confirms that every part’s checksum matches its stored metadata, ensuring your analytics stay trustworthy.
Execute CHECK TABLE db.table_name
. ClickHouse will iterate over every data part, recalculate its checksum, compare it with the value stored in checksums.txt
, and return a list of parts with a status column (0 = OK, 1 = corrupted).
Yes. Provide the partition expression: CHECK TABLE db.table_name PARTITION '2023-10'
. Narrowing the scope shortens run-time and avoids locking unrelated partitions.
For ReplicatedMergeTree tables, follow up with SYSTEM SYNC REPLICA db.table_name
. ClickHouse will download a healthy copy of any damaged part from another replica.
Use cron
or any orchestrator to run a nightly CHECK TABLE
and alert on non-zero status rows. Combine with SYSTEM SYNC REPLICA
for hands-free healing.
1) Validate the busiest partitions first. 2) Run during off-peak hours to minimize IO contention. 3) Store results in a monitoring table to trend corruption events over time.
No write lock is taken, but IO load increases. Writes continue unless you run OPTIMIZE or ALTER concurrently.
No. The command is supported only for MergeTree-family tables, including ReplicatedMergeTree and SummingMergeTree.
It indicates a checksum mismatch. The part is corrupted and should be replaced via SYSTEM SYNC REPLICA or re-ingestion.