hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Nine <t...@spidertracks.co.nz>
Subject Re: What roles do "even" nodes play in the ensamble
Date Thu, 26 Aug 2010 05:06:15 GMT
Awesome, thanks guys.  Your patience and input is greatly appreciated.





On Wed, 2010-08-25 at 21:30 -0700, Henry Robinson wrote:

> Todd - 
> 
> 
> 
> No, this is not the case. There are no 'backup' or 'failover' nodes in
> ZooKeeper. All servers that can vote are working as part of the
> cluster until they fail. You need a majority of your voting servers
> alive. 
> 
> 
> If you have three servers, a majority is of size two. The number of
> nodes that can fail before a majority is no longer alive is one. 
> If you have four servers, a majority is of size three. The number of
> nodes that can fail before a majority is no longer alive is one. 
> If you have five servers, a majority is of size three. The number of
> nodes that can fail before a majority is no longer alive is two. 
> 
> 
> This is why four servers is worse than three for availability. In both
> cases, two servers have to fail before the cluster is no longer
> available. However if failures are independently distributed, this is
> more likely to happen in a cluster of four nodes than a cluster of
> three (think of it as 'more things available to go wrong'). 
> 
> 
> If you have four servers and one dies, the 'majority' that still needs
> to be alive is still three - it doesn't drop down to two. The majority
> is of all voting servers, alive or dead. 
> 
> 
> Hope this helps - 
> 
> 
> Henry
> 
> 
> On 25 August 2010 21:01, Todd Nine <todd@spidertracks.co.nz> wrote:
> 
>         Thanks Dave.  I've been using Cassandra, so I'm trying to get
>         my head
>         around the configuration/operational differences with ZK.  You
>         state
>         that using 4 would actually decrease my reliability.  Can you
>         explain
>         that further?  I was under the impression that a 4th node
>         would act as a
>         non voting read only node until one of the other 3 fails.  I
>         thought
>         that this extra node would give me some breathing room by
>         allowing any
>         node to fail and still have 3 voting nodes.  Is this not the
>         case?
>         
>         Thanks,
>         
>         Todd
>         
>         
>         
>         
>         
>         
>         On Wed, 2010-08-25 at 21:13 -0600, Ted Dunning wrote:
>         
>         > Just use 3 nodes.  Life will be better.
>         >
>         >
>         >
>         > You can configure the fourth node in the event of one of the
>         first
>         > three failing and bring it on line.  Then you can
>         re-configure and
>         > restart each of the others one at a time.  This gives you
>         flexibility
>         > because you have 4 nodes, but doesn't decrease your
>         reliability the
>         > way that using a four node cluster would.  If you need to do
>         > maintenance on one node, just configure that node out as if
>         it had
>         > failed.
>         >
>         >
>         > On Wed, Aug 25, 2010 at 4:26 PM, Dave Wright
>         <wrightd@gmail.com>
>         > wrote:
>         >
>         >         You can certainly serve more reads with a 4th node,
>         but I'm
>         >         not sure
>         >         what you mean by "it won't have a voting role". It
>         still
>         >         participates
>         >         in voting for leaders as do all non-observers
>         regardless of
>         >         whether it
>         >         is an even or odd number. With zookeeper there is no
>         voting on
>         >         each
>         >         transaction, only leader changes.
>         >
>         >         -Dave Wright
>         >
>         >
>         >
>         >         On Wed, Aug 25, 2010 at 6:22 PM, Todd Nine
>         >         <todd@spidertracks.co.nz> wrote:
>         >         > Do I get any read performance increase (similar to
>         an
>         >         observer) since
>         >         > the node will not have a voting role?
>         >         >
>         >         >
>         >
>         >
>         >
>         >
>         
> 
> 
> 
> 
> -- 
> Henry Robinson
> Software Engineer
> Cloudera
> 415-994-6679
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message