zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Zookeeper syncing with Curator
Date Wed, 13 Mar 2019 16:07:38 GMT
It sounds like you’re describing one of the Barrier recipes. Curator has several. I’d look
to those as a possible solution. 

Jordan Zimmerman

> On Mar 13, 2019, at 9:56 AM, Robin Wolters <rbn.wolters@googlemail.com.invalid>
> Thanks for the reply. I understand that this is not possible in general.
> In my case the read and write are started from the same overarching
> application (but different zookeeper connections and hence possibly
> different nodes).
> I start the read only after I know the write has succeeded, but I
> don't know if it has reached all nodes yet.
> So I expected that a sync gives me the guarantee that the next read
> reflects at least this specific write.
> It's okay if possible further writes are not in yet.
> Is this "selective" consistency not possible with my approach?
> Best regards,
> Robin
> On Wed, 13 Mar 2019 at 15:47, Jordan Zimmerman
> <jordan@jordanzimmerman.com> wrote:
>> ZooKeeper is an eventually consistent system. Reads are always consistent in that
they reflect previous writes, however it is not possible to do what you describe. Reads are
fulfilled by the Node your client is connected to. Writes are always through the leader Node.
In a dynamic ensemble with lots of concurrent reads/writes there is no such thing a read reflecting
all active writes.
>> You should consider a RDBMS like MySQL instead of something like ZooKeeper.
>> ====================
>> Jordan Zimmerman
>>> On Mar 13, 2019, at 6:37 AM, Robin Wolters <rbn.wolters@googlemail.com.invalid>
>>> Hello,
>>> I use Zookeeper in a cluster setup and some of my read operations need
>>> to be consistent, meaning I have to make sure that a read always
>>> reflects all previous writes (which might be performed on another
>>> zookeeper server and has not reached all other instances).
>>> The idea is to force a sync before those reads to make them
>>> “consistent” reads with:
>>> client.sync().forPath(path)
>>> For this, I have these questions left:
>>> 1. Do you need to manually await the callback of sync before reading,
>>> or is the next read operation queued until the sync is complete?
>>> 2. Which amount of data is transferred between the nodes in this kind
>>> of manual sync?
>>> a) Does it always transfer and process data from the master server
>>> even if the syncing node is up-to-date on this path - or only for
>>> those nodes that are really out of sync (i.e. sync only possible
>>> deltas)?
>>> b) Does a sync on the path also force the parent nodes to sync?
>>> c) Does a sync on the path also force all child nodes to sync?
>>> d) How would one manually sync the complete data (as the regular
>>> sync does) of a node? Is client.sync().forPath("/") the way to do
>>> this?
>>> Anyone experiences with this?
>>> Best regards,
>>> Robin

View raw message