zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flavio Junqueira" <fpjunque...@yahoo.com>
Subject RE: Maximum size of a snapshot
Date Tue, 16 Jul 2013 16:16:01 GMT
The disk state should be the authoritative state of a server, so if I
remember correctly, we load the database as a way of validating the disk
state. I don't claim that this is strictly necessary, but if we are to
change it, then I would need to think this through. 

About leader election, if a leader loses support from a quorum of followers,
then it will drop leadership. Any event that causes a follower to stop
receiving messages from the leader or the follower to disconnect from the
leader will make it stop supporting the current leader.

-Flavio 

-----Original Message-----
From: Sergey Maslyakov [mailto:evolvah@gmail.com] 
Sent: 16 July 2013 16:16
To: user@zookeeper.apache.org
Subject: Re: Maximum size of a snapshot

And another extension on top of Kishore's question: do the reelections
happen if the previously elected leader remains in the cluster? In other
words, what events can trigger re-election and the corresponding temporary
degradation of the service provided by Zookeeper?


Thank you,
/Sergey


On Tue, Jul 16, 2013 at 2:21 AM, kishore g <g.kishore@gmail.com> wrote:

> Regarding #2. Is that really true that during leader election every 
> machine reloads snapshot data from disk? Any reason why this is needed 
> unless it really needs to truncate or undo conflicting transactions
already applied?
>
>
> On Mon, Jul 15, 2013 at 9:50 PM, Thawan Kooburat <thawan@fb.com> wrote:
>
> > Max snapshot size:
> >
> > Here is my take on these issue,  others feel free to add or correct.
> >
> > 1. Depends on how much RAM your machine has.  Snapshot is should be 
> > less than the available RAM since everything is loaded into memory.
> > 2. Depends on what is the availability guarantee that the client needs.
> > If there is leader election, every machine need to reload the data 
> > from disk. So the quorum will be down for at least the same as 
> > snapshot
> loading
> > time. The session timeout on the client side should be at least 
> > longer than expected downtime during leader election.
> >
> > --
> > Thawan Kooburat
> >
> >
> >
> >
> >
> > On 7/15/13 8:46 PM, "Sergey Maslyakov" <evolvah@gmail.com> wrote:
> >
> > >I have a couple of sizing questions to the users and developers. 
> > >Hope,
> you
> > >don't mind answering those.
> > >
> > >What is the guideline for the maximum reasonable size of a DataTree
> that a
> > >single ZK server can manage? If ZK server writes out a snapshot of 
> > >about 1GB in size, is it pushed beyond the limits or is it still
manageable?
> If
> > >so, where is the critical threshold when ZK is really being abused?
> > >
> > >Similarly, how can I estimate the propagation delay of a change 
> > >across
> an
> > >ensemble of three ZK servers?
> > >
> > >
> > >Thank you,
> > >/Sergey
> >
> >
>


Mime
View raw message