ClickHouse DB::Exception: No such data part

The DB::Exception: No such data part error (code NO_SUCH_DATA_PART) occurs when ClickHouse attempts to access a data part by name but cannot find it in the table's part catalog. The part may have been merged into a larger part, dropped by a TTL rule, or removed by an explicit command before the operation referencing it could complete.

Impact

Operations that reference the missing part -- such as merges, mutations, or manual ALTER TABLE ... DETACH PART commands -- will fail. If this error shows up in the replication queue, it can block subsequent entries and cause replication lag. Queries are generally unaffected unless they were explicitly targeting a specific part.

Common Causes

1. The part was merged into a larger part between the time it was referenced and the time the operation executed.
2. TTL rules deleted the part before a pending operation could use it.
3. A concurrent DROP PARTITION or TRUNCATE removed the part.
4. Manual part manipulation -- someone detached or dropped the part via ALTER TABLE commands.
5. Race condition in replication -- the replication log references a part that was replaced by a merge on another replica.

Troubleshooting and Resolution Steps

1. Check if the part was merged Look for the part in the system.part_log:

   SELECT event_type, part_name, merged_from, event_time
   FROM system.part_log
   WHERE table = 'my_table'
     AND (part_name = 'missing_part' OR has(merged_from, 'missing_part'))
   ORDER BY event_time DESC
   LIMIT 10;
   

2. Verify the part is not detached

   SELECT * FROM system.detached_parts
   WHERE table = 'my_table';
   

3. List current active parts

   SELECT name, partition, rows, active
   FROM system.parts
   WHERE table = 'my_table' AND active
   ORDER BY name;
   

4. Restart replication to clear stale references

   SYSTEM RESTART REPLICA db.my_table;
   

   This forces ClickHouse to re-evaluate the replication queue and skip entries for parts that have been superseded by merges.

5. Re-sync the replica If the replication queue is stuck:

   SYSTEM SYNC REPLICA db.my_table;
   

6. Check for concurrent operations Review whether a DROP PARTITION, TRUNCATE, or TTL cleanup ran around the same time:

   SELECT query, event_time, type
   FROM system.query_log
   WHERE query LIKE '%my_table%' AND type = 'QueryFinish'
   ORDER BY event_time DESC
   LIMIT 20;
   

Best Practices

• Avoid referencing specific part names in scripts unless necessary; parts are transient and may be merged at any time.
• Coordinate DDL operations (DROP PARTITION, TRUNCATE) across replicas to minimize race conditions.
• Monitor the system.part_log to understand part lifecycle events.
• Let ClickHouse manage merges automatically rather than forcing manual merges on specific parts.
• If using TTL, ensure that dependent operations complete before parts are eligible for deletion.

Frequently Asked Questions

Q: Does this error mean data was lost?
A: Usually no. The most common reason is that the part was merged into a larger part, and the data is still present in the merged result. Check the part log to confirm.

Q: Why does the replication queue reference a part that no longer exists?
A: Replication log entries can become stale if the underlying parts were merged or removed on another replica. ClickHouse normally handles this gracefully, but in some edge cases manual intervention is needed.

Q: Can I prevent this error from occurring?
A: It is difficult to prevent entirely because it is often a natural consequence of concurrent operations. Ensuring replicas stay in sync and avoiding conflicting DDL operations reduces the frequency.

Q: Is SYSTEM RESTART REPLICA safe to run on a production table?
A: Yes. It reinitializes the replication queue from ZooKeeper without dropping data. There may be a brief pause in replication activity during the restart.