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

Cyril Scetbon edited comment on CASSANDRA-6852 at 3/18/14 5:17 PM:
-------------------------------------------------------------------

No, I just want to understand the way it works as opposed to the way I thought 
it was working. If you can explain it with simplicity :) 

As tokens are spread before knowing what keyspaces will be created, when a hash 
value is calculated for a key to know which token will be used what cassandra 
does to be sure it won't be pushed to a node where it should not (where the 
keyspace concerned is not replicated) ?


was (Author: cscetbon):
No, I just want to understand the way it works as opposed to the way I thought 
it was working. If you can explain it with simplicity :) 

As tokens are spread before knowing what keyspaces will be created, when a hash 
value is calculated for a key to know which token will be used what cassandra 
does to be sure it won't be pushed to a node where it should not (where the 
keyspace concerned is not replicated) 

> can't repair -pr part of data when not replicating data everywhere (multiDCs)
> -----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6852
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6852
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Cyril Scetbon
>              Labels: multi-dcs, ranges, repair
>
> Our environment is as follows :
> - 3 DCS : dc1,dc2 and dc3
> - replicate all keyspaces to dc1 and dc2
> - replicate a few keyspaces to dc3 as we have less hardware and use it for 
> computing statistics
> We use repair -pr everywhere regularly. FYI, a full repair takes almost 20 
> hours per node. The matter is that we can't use "repair -pr" anymore for 
> tokens stored on dc3 concerning keyspaces not replicated. We should have a 
> way to repair those ranges without doing a FULL REPAIR everywhere



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

Reply via email to