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

On Sat, Jun 13, 2015 at 12:37 AM, Robert Coli <rc...@eventbrite.com>
wrote:

> On Fri, Jun 12, 2015 at 5:21 AM, Jens Rantil <jens.ran...@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...

Reply via email to