[
https://issues.apache.org/jira/browse/CASSANDRA-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoo Ganesh updated CASSANDRA-7233:
------------------------------------
Description:
Dropping a keyspace fails to purge the Key Cache resulting in SSTable
corruption during searches.
Dropping a full keyspace (with column families) and re-creating that same
keyspace (with column families) without restarting Cassandra causes searches to
print out CorruptSSTable messages. This has to do with the fact that keys that
reference the deleted data persist in the key cache after the data has been
deleted. Could we have the key cache automatically invalidated when for data
that is dropped?
was:
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.
> 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
> Fix For: 1.2.17
>
>
> Dropping a keyspace fails to purge the Key Cache resulting in SSTable
> corruption during searches.
> Dropping a full keyspace (with column families) and re-creating that same
> keyspace (with column families) without restarting Cassandra causes searches
> to print out CorruptSSTable messages. This has to do with the fact that keys
> that reference the deleted data persist in the key cache after the data has
> been deleted. Could we have the key cache automatically invalidated when for
> data that is dropped?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
