FT.DROPINDEX DD didn’t delete all documents in Redis Software – Redis Knowledge Base

In Redis Software deployments, the command FT.DROPINDEX <index> DD removes both the index and its indexed documents. However, not all documents are deleted if indexing was incomplete, failed due to schema/type mismatches, or if you’re running in a distributed or Active-Active cluster.
This article explains command behavior, reasons for partial deletions, and safe cleanup practices in Redis Software clusters.

Covered: How FT.DROPINDEX DD works, Common Causes, Troubleshooting, Cluster and CRDB considerations, Workarounds, and Best Practices.

Prerequisites

Redis Software cluster or Redis Stack instance with Search enabled
Access to redis-cli or the REST API
Familiarity with your index schema and key prefixing conventions

How FT.DROPINDEX DD Works

Without DD: Removes only the index definition.
With DD: Removes the index and all keys that were successfully indexed.

Deletion is asynchronous. Large datasets may take time to clear.

Syntax:

FT.DROPINDEX index-name [DD]

Read more on FT.DROPINDEX

Common Reasons for Partial Deletion

Cause	Explanation
Incomplete indexing	Only documents already indexed are removed.
Indexing failures	Documents rejected due to schema or type errors remain.
Timeouts / thread contention	Heavy load or large data sets can interrupt the deletion process.

Step-by-Step Troubleshooting

Check index status

FT.INFO <index>

Confirm:

indexing: 0
percent_indexed: 1
hash_indexing_failures: 0

If failures exist, fix data or schema issues before deletion.

Inspect Unremoved Keys

SCAN 0 MATCH <PREFIX>:* COUNT 1000 EXISTS <key>

Leftover keys likely were never indexed or were created after the index build began.

Clean Up Remaining Keys

For local cleanup:

redis-cli --scan --pattern "<PREFIX>:*" | xargs redis-cli UNLINK

Use UNLINK instead of DEL to avoid blocking.
For large clusters, use RedisGears or batch deletion scripts for safe, asynchronous cleanup.

Workarounds and Best Practices

Wait until indexing: 0 before running DD.
Always check hash_indexing_failures in FT.INFO. Read more on FT.INFO
Use consistent PREFIX values in FT.CREATE for safe key cleanup.
In CRDB deployments, perform deletion or cleanup in all peer clusters.
When performing manual deletion, prefer UNLINK over DEL to avoid blocking the main thread.
Monitor Redis Software release notes for Redis Search updates.
Ensure Redis Software and Redis Search modules are updated to the latest compatible versions. Deletion propagation issues were improved starting in Redis 7.4.

Troubleshooting Checklist

Check	Command / Action
Index fully indexed?	`FT.INFO <index>` → `indexing: 0`
Indexing errors?	`hash_indexing_failures > 0`
Prefix correct?	Verify `PREFIX` in schema
Modules up-to-date?	Review module versions
Leftover keys?	Manual cleanup with `UNLINK`

Example

FT.CREATE numeric_idx PREFIX 1 cnt: SCHEMA val NUMERIC
HSET cnt:1 val 5
HSET cnt:2 val "word"
FT.INFO numeric_idx            # Shows hash_indexing_failures: 1
FT.DROPINDEX numeric_idx DD
EXISTS cnt:1                   # (integer) 0
EXISTS cnt:2                   # (integer) 1

cnt:2 remains because it failed to index due to a schema mismatch.

Related to