cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9026) Garbage in the sstable of the secondary index
Date Wed, 25 Mar 2015 15:39:53 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380062#comment-14380062
] 

Carl Yeksigian commented on CASSANDRA-9026:
-------------------------------------------

Looks like it would be fixed by CASSANDRA-5174, but that's for 3.0.

There isn't a good way to fix the underlying index data, because we don't have a command which
will drop the index sstables and rebuild them before 3.0. You can drop the index and recreate,
but there will be some time when the index isn't created, and when the index is being built.

> Garbage in the sstable of the secondary index
> ---------------------------------------------
>
>                 Key: CASSANDRA-9026
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9026
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: CentOS 6.5
>            Reporter: Charles
>
> We create a secondary index for a specific column.
> After running a few months, by using sstable2json tool, we found there are some unknown
keys which we've never assigned are stored in the sstable of the secondary index. The key
value is incremental hexbyte, for example, 55012157, 55012158.
> It can not be removed by nodetool repair/compact/cleanup.
> When the sstable of the secondary index become larger, the read performance is dropped.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message