[
https://issues.apache.org/jira/browse/ZOOKEEPER-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010180#comment-13010180
]
Jürgen Schumacher commented on ZOOKEEPER-866:
---------------------------------------------
Ok, thanks for the answer. I have to admit that we are abusing Zookeeper and
don't have a separate cluster or separate disks for it and in such use cases
the patch does increase the throughput greatly (sorry for this ;-). So I'd like
to ask if the data loss is just a problem of the patch and can probably be
fixed (relatively) easily or if Zookeeper does really need the persistence for
providing the reliability. My (and my colleagues') impression from reading the
docs and some mails in the user lists was that the persistence (apart from
keeping the state after complete system restarts, of course) is good for faster
recovery if a server crashes and reintegrates with the ensemble, but that in
principal it should work without having any persistence at all by reading the
state from the other servers, because all the necessary data is in memory
anyway. Was this a misunderstanding?
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
