thanks. hmmm somehow I had the impression that untill B's streamingIn
finished it does not adverise itself to other servers for receiving fresh
replications. looks I'm wrong here, ler me check the code..
On Jul 28, 2015 2:07 PM, "Robert Coli" wrote:
> On Tue, Jul 28, 2015 at 1:01 PM, Yang wr
On Tue, Jul 28, 2015 at 1:01 PM, Yang wrote:
> Thanks. but I don't think having more nodes in the example changes the
> issue I outlined.
>
> say u have just key "X", rf = 3, nodes A, B, D are responsible for "X".
>
> in stable mode, the updates X=1, 2, 3, goes to all 3 servers.
>
> then at thi
Thanks. but I don't think having more nodes in the example changes the
issue I outlined.
say u have just key "X", rf = 3, nodes A, B, D are responsible for "X".
in stable mode, the updates X=1, 2, 3, goes to all 3 servers.
then at this time, node C joins, bootstraps, gets the sstables from B.
On Tue, Jul 28, 2015 at 1:31 AM, Yang wrote:
> I'm wondering how the Cassandra protocol brings a newly bootstrapped node
> "up to speed".
>
Bootstrapping nodes get "extra" replicated copies of data for the range
they are joining.
So if before the bootstrap the nodes responsible for Key "X" are
I'm wondering how the Cassandra protocol brings a newly bootstrapped node
"up to speed".
for ease of illustration, let's say we just have one key, K, and the value
is continually updated: 1,2 ,3 ,4
originally we have 1 node, A, now node B joins, and needs to bootstrap and
get its newly assig