Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 25 Mar 2015 13:51:53 +0000 (UTC)
From: "Charles (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12785086.1427179139000.22936.1427291513600@Atlassian.JIRA>
In-Reply-To: <JIRA.12785086.1427179139000@Atlassian.JIRA>
References: <JIRA.12785086.1427179139000@Atlassian.JIRA>
 <JIRA.12785086.1427179139637@arcas>
Subject: [jira] [Commented] (CASSANDRA-9026) Garbage in the sstable of the
 secondary index
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Charles commented on CASSANDRA-9026:
------------------------------------

Yes, but it does not work.
The unknown key and value is still in the sstable of secondary index.

> 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)