cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6888) Store whether a counter sstable still use some local/remote shards in the sstable metadata
Date Mon, 31 Mar 2014 20:31:16 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-6888:
-----------------------------------------

         Reviewer: Sylvain Lebresne
    Fix Version/s:     (was: 2.1)
                   2.1 beta2

> Store whether a counter sstable still use some local/remote shards in the sstable metadata
> ------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6888
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6888
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Aleksey Yeschenko
>             Fix For: 2.1 beta2
>
>
> CASSANDRA-6504 has made so we don't distinguish different type of shard in counters.
Yet, even though we don't generate those local/remote type of shards, those won't disappear
just by running upgradesstable, they need to be compacted away (and even then, they really
only disappear if there has been a new update on the counter post-6504).
> But we want to get rid of those ultimately, since they make things like CASSANDRA-6506
less optimal. Now, even though the final step of that remain to be discussed, the first step
is probably to keep track of whether such shard still exist in the system or not. That part
is simple, we can just store a boolean in the SSTableMetadata to say whether or not said sstable
still has at least one Cell using such old shard type. 



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

Mime
View raw message