incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Kochen <rene.koc...@schange.com>
Subject Re: Make an existing cluster multi data-center compatible.
Date Tue, 05 Aug 2014 21:27:58 GMT
"As long as you correctly configure the new snitch so that the replica sets
do not change, no, you do not need to repair."

Is the following correct:

The replica sets do not change if you modify the snitch from SimpleSnitch
to NetworkTopologyStrategy and the topology file puts all nodes in the same
data-center and rack.

Thanks again!

Rene


2014-08-05 20:05 GMT+02:00 Robert Coli <rcoli@eventbrite.com>:

> On Tue, Aug 5, 2014 at 3:52 AM, Rene Kochen <rene.kochen@schange.com>
> wrote:
>
>> Do I have to run full repairs after this change? Because the yaml file
>> states: IF YOU CHANGE THE SNITCH AFTER DATA IS INSERTED INTO THE CLUSTER,
>> YOU MUST RUN A FULL REPAIR, SINCE THE SNITCH AFFECTS WHERE REPLICAS ARE
>> PLACED.
>>
>
> As long as you correctly configure the new snitch so that the replica sets
> do not change, no, you do not need to repair.
>
> Barring that, if you manage to transform the replica set in such a way
> that you always have one (fully repaired) replica from the old set, repair
> will help. I do not recommend this very risky practice. In practice the
> only transformation of snitch in a cluster with data which is likely to be
> safe is one whose result is a NOOP in terms of replica placement.
>
> In fact, the yaml file is stating something unreasonable there, because
> repair cannot protect against this case :
>
> - 6 node cluster, A B C D E F,  RF = 2
>
> 1) Start with SimpleSnitch so that A, B have the two replicas of row key X.
> 2) Write row key X, value Y, to nodes A and B.
> 2) Change to OtherSnitch so that now C,D are responsible for row key X.
> 3) Repair and notice that neither C nor D answer "Y" when asked for row X.
>
> =Rob
>
>

Mime
View raw message