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" <rc...@eventbrite.com> wrote:
> On Tue, Jul 28, 2015 at 1:01 PM, Yang <teddyyyy...@gmail.com> 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 this time, node C joins, bootstraps, gets the sstables from B. >> but on B, ***right after memtableswitch()***, updates X=4,5,6 arrive and >> update the new memtable (the same updates also go to A and D). then B >> continues to stream to C, and C gets its state to X=3. >> > > You appear to be missing the point in my original mail : the memtable > switch is irrelevant, because C is receiving the same writes into memtables > that B is. > > They're not counted for the purposes of consistency, but they are > otherwise received just as if C were a an actual replica. > > Bootstrapping is two parts : > > 1) streaming of sstables > 2) "extra" replication > > Your mental model appears to ignore 2), which is why you care what > flushed? Perhaps I am still misunderstanding the scenario you are > describing? > > =Rob > >
