cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinoo Ganesh (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-7233) Dropping a keyspace fails to purge the Key Cache resulting in SSTable Corruption during searches
Date Wed, 14 May 2014 20:29:14 GMT
Vinoo Ganesh created CASSANDRA-7233:
---------------------------------------

             Summary: Dropping a keyspace fails to purge the Key Cache resulting in SSTable
Corruption during searches
                 Key: CASSANDRA-7233
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7233
             Project: Cassandra
          Issue Type: Bug
          Components: Core
            Reporter: Vinoo Ganesh


Dropping a keyspace fails to purge the Key Cache resulting in SSTable corruption during searches.

One of our workflows involves dropping a full keyspace (with column families) and re-creating
it all without restarting Cassandra. When data is dropped from Cassandra, it doesn't look
the key cache is invalidated which causes searches to print out CorruptSSTable messages. 


At an initial glance, it looks like the issue we're seeing has to do with the fact that the
Descriptor passed into KeyCacheKey's constructor checks directory, generation, ksname, cfname,
and temp. In our workflow, when the new keyspace is created, generation restarts at 1 which
creates issues. 

We're not sure if it makes a lot of sense to try and preserve the generation during the deletion/recreation
process (and we're not sure where Cassandra would even save this) but that would be a fix
for our workflow. 

Additionally, making the actual Column Family UUIDs unique would be great as well. It looks
like in RowKeyCache, they UUIDs are just made up of the keyspace name and column family. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message