You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Patrick Hunt (JIRA)" <ji...@apache.org> on 2009/10/08 18:40:31 UTC
[jira] Created: (ZOOKEEPER-546) add "diskless" ensemble support
add "diskless" ensemble support
-------------------------------
Key: ZOOKEEPER-546
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-546
Project: Zookeeper
Issue Type: New Feature
Components: server
Reporter: Patrick Hunt
Fix For: 3.3.0
In some cases there is no need to have the ZK data persisted to disk. For example if all you are doing is group membership and leadership
election the data is totally ephemeral, storing on disk is unnecessary. We've also seen cases where any non-ephemeral data can be
easily recovered (say configuration data that's generated/read and loaded into zk) and there is less need to worry about recovery of the
data in the case of catastrophic failure (meaning _all_ replicas are lost, remember, recovery is automatic if 2n+1 servers and <= n servers
fail, even if > n fail manual recovery is still possible as long as at least 1 replica, or replica backup can be recovered)
In these cases it makes sense to have a "diskless" zookeeper ensemble. The result should be improved write performance
an less moving parts (no disk to fail!), simplifiying ops in cases where this can be applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-546) add "diskless" ensemble support
Posted by "Andrei Savu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Savu resolved ZOOKEEPER-546.
-----------------------------------
Resolution: Duplicate
Closing as a duplicate of ZOOKEEPER-866 (already has a patch attached).
> add "diskless" ensemble support
> -------------------------------
>
> Key: ZOOKEEPER-546
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-546
> Project: Zookeeper
> Issue Type: New Feature
> Components: server
> Reporter: Patrick Hunt
> Fix For: 3.4.0
>
>
> In some cases there is no need to have the ZK data persisted to disk. For example if all you are doing is group membership and leadership
> election the data is totally ephemeral, storing on disk is unnecessary. We've also seen cases where any non-ephemeral data can be
> easily recovered (say configuration data that's generated/read and loaded into zk) and there is less need to worry about recovery of the
> data in the case of catastrophic failure (meaning _all_ replicas are lost, remember, recovery is automatic if 2n+1 servers and <= n servers
> fail, even if > n fail manual recovery is still possible as long as at least 1 replica, or replica backup can be recovered)
> In these cases it makes sense to have a "diskless" zookeeper ensemble. The result should be improved write performance
> an less moving parts (no disk to fail!), simplifiying ops in cases where this can be applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-546) add "diskless" ensemble support
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Hunt updated ZOOKEEPER-546:
-----------------------------------
Fix Version/s: (was: 3.3.0)
3.4.0
> add "diskless" ensemble support
> -------------------------------
>
> Key: ZOOKEEPER-546
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-546
> Project: Zookeeper
> Issue Type: New Feature
> Components: server
> Reporter: Patrick Hunt
> Fix For: 3.4.0
>
>
> In some cases there is no need to have the ZK data persisted to disk. For example if all you are doing is group membership and leadership
> election the data is totally ephemeral, storing on disk is unnecessary. We've also seen cases where any non-ephemeral data can be
> easily recovered (say configuration data that's generated/read and loaded into zk) and there is less need to worry about recovery of the
> data in the case of catastrophic failure (meaning _all_ replicas are lost, remember, recovery is automatic if 2n+1 servers and <= n servers
> fail, even if > n fail manual recovery is still possible as long as at least 1 replica, or replica backup can be recovered)
> In these cases it makes sense to have a "diskless" zookeeper ensemble. The result should be improved write performance
> an less moving parts (no disk to fail!), simplifiying ops in cases where this can be applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.