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
>
|