zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camille Fournier <cami...@apache.org>
Subject Re: sometimes I can't read data I just wrote..race condition or misunderstanding?
Date Tue, 04 Mar 2014 20:25:49 GMT
Is the same client issuing the write and the read? If so, you should see
the data you wrote. Otherwise, you may be connected to a lagging client, as
Raul says.

C


On Tue, Mar 4, 2014 at 3:22 PM, Raúl Gutiérrez Segalés
<rgs@itevenworks.net>wrote:

> On 4 March 2014 07:21, Brian Tarbox <briantarbox@gmail.com> wrote:
>
> > We're running a five node cluster in AWS and sometimes if I do a read
> > immediately after doing a write ZK does not find the data I just wrote.
> >
> > I may just have a flawed model but is this a case of "writes go to the
> > master, while reads can go to any node in the cluster?".  We are thinking
> > that perhaps our write went to the master and then our read went to a
> > follower that hadn't gotten the write yet?
> >
>
> Perhaps you can call sync() to ensure reads after writes?
>
>
> > Along the same lines...when does a watch fire?  After the leader has the
> > change or after all followers have gotten the change?
> >
>
> The pipeline is, in a poor's man diagram, as follow:
>
>
> client → write request → zk_server_1
>                                               ↓
>                                               ↓
>                       write request is sent to the leader
>                                               ↓
>                                               ↓
>              leader fans out a transaction proposal to all followers
>                                               ↓
>                                               ↓
>             ↓                ↓                           ↓
> ↓
>        follower 1     follower 2              follower 3         follower 4
>                                               ↓
>                                               ↓
>                followers, non-synchronously, acknowledge the proposal
>                                               ↓
>                                               ↓
>      when the leader gets a sufficient number of acks (from a "majority")
> it fans out COMMIT msgs to followers
>                                               ↓
>                                               ↓
>             ↓                ↓                           ↓
> ↓
>        follower 1     follower 2              follower 3         follower 4
>                                               ↓
>                                               ↓
>        followers will then apply the write which triggers watches, that in
> turn will then flow to listening clients...
>
>
> Hth,
> -rgs
>

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