curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Kim <ohech...@gmail.com>
Subject Re: Client's Host Selection
Date Thu, 02 May 2013 01:09:50 GMT
Thanks for the link.

I am aware of some of these issues but they haven't been become a blocking
issue yet. I'm using it for locking so I always need a global view (at
least until some point when I may have to do some more clever sharding of
data). The cross DC latency hasn't been too harsh. Usually on the order of
20 ms. Applications only hitting the local ZK does help so I set up haproxy
to handle that. However, the created a problem when I did the same in
Cassandra because haproxy couldn't see the application errors and it hurt
the client's ability to failover. It had a configurable load balancing
policy though that favored more local nodes.

Anyway, for posterity, I asked on ZK and they said it doesn't really. The C
client can force a deterministic order but Java is currently only random.


On Wed, May 1, 2013 at 5:27 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> * ZooKeeper is not internal data center aware.
> * There is always a leader and all writes go through the leader
> * All writes must go to a quorum
> * You can remedy this somewhat with Observers, but the ensemble will still
> need connection to the leader
>
> This article is a good reference:
> http://whilefalse.blogspot.com/2012/12/building-global-highly-available.html
>
> On May 1, 2013, at 5:23 PM, Owen Kim <ohechkay@gmail.com> wrote:
>
> Why do you advise against cross-DC ZK? Does it impact anything besides
> latency?
>
>
>

Mime
View raw message