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?
Along the same lines...when does a watch fire? After the leader has the change or after all followers have gotten the change?
On 4 March 2014 07:21, Brian Tarbox <[EMAIL PROTECTED]> wrote: Perhaps you can call sync() to ensure reads after writes?
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
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 <[EMAIL PROTECTED]>wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext