(Cassandra 2.0.9, using CQL)
I've accidentally updated a row in a table which was managing its own timestamp (100 * a specific sequence number). Now, because my timestamp is the current time, none of the updates are working. I understand why this is, but I'm trying to recover from it. I'm fortunate that I can delete these rows.
I've set gc_grace_seconds to 0 and run delete from table where key=primarykey to remove the rows. After, I've used nodetool flush and nodetool compact on every node to cause the deletion to go through and get the resulting tombstones compacted and erased. I've then bumped gc_grace_seconds back up to 10 days and tried to insert into a row with the same key but using timestamp 1 .
This doesn't work. Just wondering if anyone has done a similar mistake and worked around it?
I thought I would give this exercise a try.
Here is a look at how the data is stored, using the
cassandra-cli
:I will now delete the
data
column for this row, generating a tombstone:When I SELECT with
tracing on
I can see that the column shows "null" and I have a tombstone out there.So I will set the
bladerunners
table'sgc_grace_seconds
to zero:From the (Linux) command line, I will flush and compact my
presentation
keyspace:When I SELECT with
tracing on
, I can see that thedata
column is still "null," but now the tombstone is gone.I will now re-INSERT the
data
column with a timestamp of 1:When querying with the
cassandra-cli
, this is now what I see:Note that the
data
column now has a timestamp of 1.Try running your query with
tracing on
and see if your tombstones are really gone. Also, check your table via thecassandra-cli
to see how the timestamps are coming through. Let me know if you need clarification on any of these steps.NOTE: I was just showing the flush/compact as part of the example or exercise. I feel compelled to mention that DataStax recommends that users avoid manually running
nodetool compact
if at all possible.