cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alain RODRIGUEZ <arodr...@gmail.com>
Subject Re: Question regarding concurrent bootstrapping
Date Tue, 16 Jun 2015 21:26:20 GMT
Hi Jens,

if you are going to dramatically change the number of nodes or for a lot of
high movement in tokens you might want to consider DC switching - adding a
DC, switching client, dropping old DC. You can use this also for a few
other cases like using vnodes, changing their number or even the
partitioner. This is quite efficient and safe if you can afford doubling
your servers (cloud ?).

Alain

2015-06-14 20:01 GMT+02:00 Jens Rantil <jens.rantil@tink.se>:

> Rob,
>
> Thanks for a great answer. While I'm at it, thanks for all the time you
> put into answering people on this mailing list. I'm sure I'm not the only
> appreciating it.
>
> Cheers,
> Jens
>
> –
> Skickat från Mailbox <https://www.dropbox.com/mailbox>
>
>
> On Sat, Jun 13, 2015 at 12:37 AM, Robert Coli <rcoli@eventbrite.com>
> wrote:
>
>> On Fri, Jun 12, 2015 at 5:21 AM, Jens Rantil <jens.rantil@tink.se> wrote:
>>
>>> Let's say I have an existing cluster and do the following:
>>>
>>>    1. I start a new joining node (A). It enters state "Up/Joining".
>>>    Streaming automatically start to this node.
>>>    2. I wait two minutes (best practise for bootstrapping).
>>>    3. I start a second node (B) to join the cluster. It allocates some
>>>    of A:s previous parts of the ring and enters state "Up/Joining". Streaming
>>>    automatically starts to this node.
>>>
>>> Will streaming of data that A is no longer responsible (after B joined)
>>> stop immediately? That is, after (3), will data streamed to A only be what
>>> it is responsible of?
>>>
>>
>> It depends on the version of Cassandra. A will get data it "shouldn't"
>> get in any version that doesn't contain CASSANDRA-2434 patch. If you do not
>> run "cleanup" on A when A is done bootstrapping
>>
>> In a version containing 2434, the attempt to bootstrap B will fail and
>> will not work until A is done bootstrapping, unless you set the
>> property -Dcassandra.consistent.rangemovement=false while starting it.
>>
>> In general, one DOES NOT WANT TO
>> SET -Dcassandra.consistent.rangemovement!!!!! It fixes 2434, and 2434 is
>> bad for consistency.
>>
>> Instead, considering expanding clusters to initial size when they are
>> empty, and disabling bootstrapping while doing so.
>>
>> Lots and lots of background on :
>> https://issues.apache.org/jira/browse/CASSANDRA-2434
>>
>>  Related ticket : https://issues.apache.org/jira/browse/CASSANDRA-7069
>>
>>  =Rob
>> PS - BTW, the fact that 2434 existed for so long, in versions where
>> repair was often broken/unused, is the strongest single item of information
>> in support of the Coli Conjecture...
>>
>
>

Mime
View raw message