If I delete every keys in a ColumnFamily in a Cassandra db using remove(key)
, then if I use get_range_slices
, rows are still there but without columns. How could I remove entire rows?

- 5,753
- 72
- 57
- 129

- 6,885
- 14
- 63
- 99
3 Answers
Why do deleted keys show up during range scans?
Because get_range_slice says, "apply this predicate to the range of rows given," meaning, if the predicate result is empty, we have to include an empty result for that row key. It is perfectly valid to perform such a query returning empty column lists for some or all keys, even if no deletions have been performed.

- 80,295
- 52
- 162
- 195

- 20,702
- 12
- 62
- 79
-
Thanks and there is no solution to avoid that? – Matroska Jun 05 '10 at 21:06
-
2According to http://wiki.apache.org/cassandra/DistributedDeletes, the tombstones are cleaned up every GCGraceSeconds, which is 10 days by default. GCGraceSeconds should be the max amount of time it will ever take you to get a failed node back up and running. For a singled instance, you can set GCGraceSeconds to 0, and then the tombstones will be deleted automatically. – Ryan Shillington Apr 04 '13 at 05:05
Cassandra uses Distributed Deletes as expected.
Thus, a delete operation can't just wipe out all traces of the data being removed immediately: if we did, and a replica did not receive the delete operation, when it becomes available again it will treat the replicas that did receive the delete as having missed a write update, and repair them! So, instead of wiping out data on delete, Cassandra replaces it with a special value called a tombstone. The tombstone can then be propagated to replicas that missed the initial remove request.

- 13,411
- 17
- 77
- 120
Just been having the same issue and I found that:
This has been fixed in 0.7 (https://issues.apache.org/jira/browse/CASSANDRA-1027). And backported to 0.6.3
This is also relevant: https://issues.apache.org/jira/browse/CASSANDRA-494

- 18
- 1
-
4-1 This has not been "fixed", the ticket has just been "resolved" and the resolution is "[maybe do it] later". As per @Schildmeijer's answer, this is expected behavior, as opposed to a bug. – user359996 Mar 19 '12 at 00:19
-