[
https://issues.apache.org/jira/browse/ZOOKEEPER-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906344#action_12906344
]
Flavio Junqueira commented on ZOOKEEPER-866:
--------------------------------------------
I have a few concerns about your proposals, Thomas. Making just part of the
state persistent is prone to error, since failure and recovery of enough
replicas may lead to different and inconsistent views of the zookeeper state
over time. Also, would we enforce that a child is persistent only if the parent
is persistent? Delaying persistence of data could also cause inconsistent views
of the zookeeper state over time (some data disappearing).
Alternatively, we could simply assume that at no time there is more than a
quorum of crashed, and if you're happy with this proposal, then you
modifications wouldn't be necessary. In fact, I believe this is an assumption
that Mahadev's proposal makes to guarantee a correct behavior.
One feature that might be useful is a direct command to a zookeeper server to
have it dump its state to disk. Suppose that I'm operating a purely in-memory
ensemble as proposed in this jira, and I want to shut down all servers for
maintenance, but don't want to lose my state. I could stop all clients, command
the servers to dump their state, and shut them down gracefully.
> Adding no disk persistence option in zookeeper.
> -----------------------------------------------
>
> Key: ZOOKEEPER-866
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-866
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Mahadev konar
> Assignee: Mahadev konar
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-nodisk.patch
>
>
> Its been seen that some folks would like to use zookeeper for very fine
> grained locking. Also, in there use case they are fine with loosing all old
> zookeeper state if they reboot zookeeper or zookeeper goes down. The use case
> is more of a runtime locking wherein forgetting the state of locks is
> acceptable in case of a zookeeper reboot. Not logging to disk allows high
> throughput on and low latency on the writes to zookeeper. This would be a
> configuration option to set (ofcourse the default would be logging to disk).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
