You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Bill Hastings <bl...@gmail.com> on 2010/05/02 18:29:51 UTC
Bootstrap source code
Hi
I have looking at the bootstrap source and seem to understand it for the
most part. This is what I do not follow:
(1) New node joins and doesn't advertise its token.
(2) Requests nodes to send it data. The nodes that need to send it data
first flush memtables and then transfer SSTables.
Once the streaming is over the new node advertises its token and starts
handling reads and writes correct? But what happens to keys that are being
written to the old nodes after the memtables have been dumped. Looks like
there is a window where keys would be going to the old nodes and not making
it to the new nodes. Am I missing something here.
--
Cheers
Bill
Re: Bootstrap source code
Posted by Jonathan Ellis <jb...@gmail.com>.
StorageService.initServer
On Thu, May 6, 2010 at 12:30 AM, Bill Hastings <bl...@gmail.com> wrote:
> Ah. That makes sense. All nodes start up in bootstrap mode. So on start up
> where in the code do I need to look to figure out that bootstrap is not
> required resulting in a call to finishBootstrap().
>
>
> On Tue, May 4, 2010 at 6:36 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
>> AbstractReplicationStrategy.getWriteEndpoints is where bootstrapping
>> nodes get added as write destinations.
>>
>> On Tue, May 4, 2010 at 6:02 PM, Bill Hastings <bl...@gmail.com>
>> wrote:
>> > Hi
>> >
>> > I did some more looking. It looks like on bootstrap the token gets added
>> to
>> > the bootstrapTokens list. However there is no change to the
>> > tokenToEndPointMap. So how do writes make it to the new node. It is only
>> > when bootstrap is complete are the tokens removed from bootstrapTokens
>> list
>> > added to the tokenToEndPointMap opening them up to the ring. Which means
>> > during bootstrap writes continue to go to the old nodes and the when
>> > bootstrap is complete there could be some data that was written during
>> the
>> > bootstrap that remains on the old node. Am I missing something here? Any
>> > pointers would be great.
>> >
>> > Cheers
>> > - bill
>> >
>> >
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: Stu Hood <st...@rackspace.com>
>> >> Date: Sun, May 2, 2010 at 10:50 AM
>> >> Subject: Re: Bootstrap source code
>> >> To: dev@cassandra.apache.org
>> >>
>> >>
>> >> Nodes declare that they will be joining the ring at a particular
>> position,
>> >> which makes them a member of the 'pending ranges' set. Nodes with
>> pending
>> >> ranges are supposed to receive writes for those ranges, despite not
>> >> officially owning them yet.
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: "Roger Schildmeijer" <sc...@gmail.com>
>> >> Sent: Sunday, May 2, 2010 11:50am
>> >> To: dev@cassandra.apache.org
>> >> Subject: Re: Bootstrap source code
>> >>
>> >> s/hinted handoff/read repair
>> >>
>> >> >
>> >> >
>> >> >
>> >> > (Moved to developers mailing list)
>> >> >
>> >> > Without delve to deep into to that part of the code my educated(?)
>> guess
>> >> is that this will (eventually) be solved/repaired thanks to hinted
>> handoff
>> >> and anti entropy service.
>> >> >
>> >> >
>> >> > On 2 maj 2010, at 18.29em, Bill Hastings wrote:
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> I have looking at the bootstrap source and seem to understand it for
>> the
>> >> most part. This is what I do not follow:
>> >> >>
>> >> >> (1) New node joins and doesn't advertise its token.
>> >> >> (2) Requests nodes to send it data. The nodes that need to send it
>> data
>> >> first flush memtables and then transfer SSTables.
>> >> >>
>> >> >> Once the streaming is over the new node advertises its token and
>> starts
>> >> handling reads and writes correct? But what happens to keys that are
>> being
>> >> written to the old nodes after the memtables have been dumped. Looks
>> like
>> >> there is a window where keys would be going to the old nodes and not
>> making
>> >> it to the new nodes. Am I missing something here.
>> >> >>
>> >> >> --
>> >> >> Cheers
>> >> >> Bill
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers
>> > Bill
>> >
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of Riptano, the source for professional Cassandra support
>> http://riptano.com
>>
>
>
>
> --
> Cheers
> Bill
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: Bootstrap source code
Posted by Bill Hastings <bl...@gmail.com>.
Ah. That makes sense. All nodes start up in bootstrap mode. So on start up
where in the code do I need to look to figure out that bootstrap is not
required resulting in a call to finishBootstrap().
On Tue, May 4, 2010 at 6:36 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> AbstractReplicationStrategy.getWriteEndpoints is where bootstrapping
> nodes get added as write destinations.
>
> On Tue, May 4, 2010 at 6:02 PM, Bill Hastings <bl...@gmail.com>
> wrote:
> > Hi
> >
> > I did some more looking. It looks like on bootstrap the token gets added
> to
> > the bootstrapTokens list. However there is no change to the
> > tokenToEndPointMap. So how do writes make it to the new node. It is only
> > when bootstrap is complete are the tokens removed from bootstrapTokens
> list
> > added to the tokenToEndPointMap opening them up to the ring. Which means
> > during bootstrap writes continue to go to the old nodes and the when
> > bootstrap is complete there could be some data that was written during
> the
> > bootstrap that remains on the old node. Am I missing something here? Any
> > pointers would be great.
> >
> > Cheers
> > - bill
> >
> >
> >>
> >> ---------- Forwarded message ----------
> >> From: Stu Hood <st...@rackspace.com>
> >> Date: Sun, May 2, 2010 at 10:50 AM
> >> Subject: Re: Bootstrap source code
> >> To: dev@cassandra.apache.org
> >>
> >>
> >> Nodes declare that they will be joining the ring at a particular
> position,
> >> which makes them a member of the 'pending ranges' set. Nodes with
> pending
> >> ranges are supposed to receive writes for those ranges, despite not
> >> officially owning them yet.
> >>
> >>
> >> -----Original Message-----
> >> From: "Roger Schildmeijer" <sc...@gmail.com>
> >> Sent: Sunday, May 2, 2010 11:50am
> >> To: dev@cassandra.apache.org
> >> Subject: Re: Bootstrap source code
> >>
> >> s/hinted handoff/read repair
> >>
> >> >
> >> >
> >> >
> >> > (Moved to developers mailing list)
> >> >
> >> > Without delve to deep into to that part of the code my educated(?)
> guess
> >> is that this will (eventually) be solved/repaired thanks to hinted
> handoff
> >> and anti entropy service.
> >> >
> >> >
> >> > On 2 maj 2010, at 18.29em, Bill Hastings wrote:
> >> >
> >> >> Hi
> >> >>
> >> >> I have looking at the bootstrap source and seem to understand it for
> the
> >> most part. This is what I do not follow:
> >> >>
> >> >> (1) New node joins and doesn't advertise its token.
> >> >> (2) Requests nodes to send it data. The nodes that need to send it
> data
> >> first flush memtables and then transfer SSTables.
> >> >>
> >> >> Once the streaming is over the new node advertises its token and
> starts
> >> handling reads and writes correct? But what happens to keys that are
> being
> >> written to the old nodes after the memtables have been dumped. Looks
> like
> >> there is a window where keys would be going to the old nodes and not
> making
> >> it to the new nodes. Am I missing something here.
> >> >>
> >> >> --
> >> >> Cheers
> >> >> Bill
> >> >
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Cheers
> > Bill
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>
--
Cheers
Bill
Re: Bootstrap source code
Posted by Jonathan Ellis <jb...@gmail.com>.
AbstractReplicationStrategy.getWriteEndpoints is where bootstrapping
nodes get added as write destinations.
On Tue, May 4, 2010 at 6:02 PM, Bill Hastings <bl...@gmail.com> wrote:
> Hi
>
> I did some more looking. It looks like on bootstrap the token gets added to
> the bootstrapTokens list. However there is no change to the
> tokenToEndPointMap. So how do writes make it to the new node. It is only
> when bootstrap is complete are the tokens removed from bootstrapTokens list
> added to the tokenToEndPointMap opening them up to the ring. Which means
> during bootstrap writes continue to go to the old nodes and the when
> bootstrap is complete there could be some data that was written during the
> bootstrap that remains on the old node. Am I missing something here? Any
> pointers would be great.
>
> Cheers
> - bill
>
>
>>
>> ---------- Forwarded message ----------
>> From: Stu Hood <st...@rackspace.com>
>> Date: Sun, May 2, 2010 at 10:50 AM
>> Subject: Re: Bootstrap source code
>> To: dev@cassandra.apache.org
>>
>>
>> Nodes declare that they will be joining the ring at a particular position,
>> which makes them a member of the 'pending ranges' set. Nodes with pending
>> ranges are supposed to receive writes for those ranges, despite not
>> officially owning them yet.
>>
>>
>> -----Original Message-----
>> From: "Roger Schildmeijer" <sc...@gmail.com>
>> Sent: Sunday, May 2, 2010 11:50am
>> To: dev@cassandra.apache.org
>> Subject: Re: Bootstrap source code
>>
>> s/hinted handoff/read repair
>>
>> >
>> >
>> >
>> > (Moved to developers mailing list)
>> >
>> > Without delve to deep into to that part of the code my educated(?) guess
>> is that this will (eventually) be solved/repaired thanks to hinted handoff
>> and anti entropy service.
>> >
>> >
>> > On 2 maj 2010, at 18.29em, Bill Hastings wrote:
>> >
>> >> Hi
>> >>
>> >> I have looking at the bootstrap source and seem to understand it for the
>> most part. This is what I do not follow:
>> >>
>> >> (1) New node joins and doesn't advertise its token.
>> >> (2) Requests nodes to send it data. The nodes that need to send it data
>> first flush memtables and then transfer SSTables.
>> >>
>> >> Once the streaming is over the new node advertises its token and starts
>> handling reads and writes correct? But what happens to keys that are being
>> written to the old nodes after the memtables have been dumped. Looks like
>> there is a window where keys would be going to the old nodes and not making
>> it to the new nodes. Am I missing something here.
>> >>
>> >> --
>> >> Cheers
>> >> Bill
>> >
>>
>>
>>
>>
>>
>
>
> --
> Cheers
> Bill
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: Bootstrap source code
Posted by Bill Hastings <bl...@gmail.com>.
Hi
I did some more looking. It looks like on bootstrap the token gets added to
the bootstrapTokens list. However there is no change to the
tokenToEndPointMap. So how do writes make it to the new node. It is only
when bootstrap is complete are the tokens removed from bootstrapTokens list
added to the tokenToEndPointMap opening them up to the ring. Which means
during bootstrap writes continue to go to the old nodes and the when
bootstrap is complete there could be some data that was written during the
bootstrap that remains on the old node. Am I missing something here? Any
pointers would be great.
Cheers
- bill
>
> ---------- Forwarded message ----------
> From: Stu Hood <st...@rackspace.com>
> Date: Sun, May 2, 2010 at 10:50 AM
> Subject: Re: Bootstrap source code
> To: dev@cassandra.apache.org
>
>
> Nodes declare that they will be joining the ring at a particular position,
> which makes them a member of the 'pending ranges' set. Nodes with pending
> ranges are supposed to receive writes for those ranges, despite not
> officially owning them yet.
>
>
> -----Original Message-----
> From: "Roger Schildmeijer" <sc...@gmail.com>
> Sent: Sunday, May 2, 2010 11:50am
> To: dev@cassandra.apache.org
> Subject: Re: Bootstrap source code
>
> s/hinted handoff/read repair
>
> >
> >
> >
> > (Moved to developers mailing list)
> >
> > Without delve to deep into to that part of the code my educated(?) guess
> is that this will (eventually) be solved/repaired thanks to hinted handoff
> and anti entropy service.
> >
> >
> > On 2 maj 2010, at 18.29em, Bill Hastings wrote:
> >
> >> Hi
> >>
> >> I have looking at the bootstrap source and seem to understand it for the
> most part. This is what I do not follow:
> >>
> >> (1) New node joins and doesn't advertise its token.
> >> (2) Requests nodes to send it data. The nodes that need to send it data
> first flush memtables and then transfer SSTables.
> >>
> >> Once the streaming is over the new node advertises its token and starts
> handling reads and writes correct? But what happens to keys that are being
> written to the old nodes after the memtables have been dumped. Looks like
> there is a window where keys would be going to the old nodes and not making
> it to the new nodes. Am I missing something here.
> >>
> >> --
> >> Cheers
> >> Bill
> >
>
>
>
>
>
--
Cheers
Bill
Re: Bootstrap source code
Posted by Stu Hood <st...@rackspace.com>.
Nodes declare that they will be joining the ring at a particular position, which makes them a member of the 'pending ranges' set. Nodes with pending ranges are supposed to receive writes for those ranges, despite not officially owning them yet.
-----Original Message-----
From: "Roger Schildmeijer" <sc...@gmail.com>
Sent: Sunday, May 2, 2010 11:50am
To: dev@cassandra.apache.org
Subject: Re: Bootstrap source code
s/hinted handoff/read repair
>
>
>
> (Moved to developers mailing list)
>
> Without delve to deep into to that part of the code my educated(?) guess is that this will (eventually) be solved/repaired thanks to hinted handoff and anti entropy service.
>
>
> On 2 maj 2010, at 18.29em, Bill Hastings wrote:
>
>> Hi
>>
>> I have looking at the bootstrap source and seem to understand it for the most part. This is what I do not follow:
>>
>> (1) New node joins and doesn't advertise its token.
>> (2) Requests nodes to send it data. The nodes that need to send it data first flush memtables and then transfer SSTables.
>>
>> Once the streaming is over the new node advertises its token and starts handling reads and writes correct? But what happens to keys that are being written to the old nodes after the memtables have been dumped. Looks like there is a window where keys would be going to the old nodes and not making it to the new nodes. Am I missing something here.
>>
>> --
>> Cheers
>> Bill
>
Re: Bootstrap source code
Posted by Roger Schildmeijer <sc...@gmail.com>.
s/hinted handoff/read repair
>
>
>
> (Moved to developers mailing list)
>
> Without delve to deep into to that part of the code my educated(?) guess is that this will (eventually) be solved/repaired thanks to hinted handoff and anti entropy service.
>
>
> On 2 maj 2010, at 18.29em, Bill Hastings wrote:
>
>> Hi
>>
>> I have looking at the bootstrap source and seem to understand it for the most part. This is what I do not follow:
>>
>> (1) New node joins and doesn't advertise its token.
>> (2) Requests nodes to send it data. The nodes that need to send it data first flush memtables and then transfer SSTables.
>>
>> Once the streaming is over the new node advertises its token and starts handling reads and writes correct? But what happens to keys that are being written to the old nodes after the memtables have been dumped. Looks like there is a window where keys would be going to the old nodes and not making it to the new nodes. Am I missing something here.
>>
>> --
>> Cheers
>> Bill
>
Re: Bootstrap source code
Posted by Roger Schildmeijer <sc...@gmail.com>.
(Moved to developers mailing list)
Without delve to deep into to that part of the code my educated(?) guess is that this will (eventually) be solved/repaired thanks to hinted handoff and anti entropy service.
On 2 maj 2010, at 18.29em, Bill Hastings wrote:
> Hi
>
> I have looking at the bootstrap source and seem to understand it for the most part. This is what I do not follow:
>
> (1) New node joins and doesn't advertise its token.
> (2) Requests nodes to send it data. The nodes that need to send it data first flush memtables and then transfer SSTables.
>
> Once the streaming is over the new node advertises its token and starts handling reads and writes correct? But what happens to keys that are being written to the old nodes after the memtables have been dumped. Looks like there is a window where keys would be going to the old nodes and not making it to the new nodes. Am I missing something here.
>
> --
> Cheers
> Bill