zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Bridge (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-1508) Reliable standalone mode through redundant databases
Date Thu, 12 Jul 2012 00:19:35 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412401#comment-13412401

Bill Bridge commented on ZOOKEEPER-1508:

It would certainly have to be an option that has no effect on users that do not want it. If
you never heard the new feature exists, you would not notice any change. If you used the feature
it would be possible to go back to not using it without any loss of data, or reformatting
of the database. Step 1 below would require shutdown.

I was thinking that it could be done in 3 steps that each introduce additional functionality.
# Support multiple destinations. If one fails simply stop writing to it. Manual shutdown,
snapshot copy, and startup would be required to restore redundancy.
# Online reconfiguration of destinations after a failure, or for changing redundancy without
a shutdown.
# Automatic fail-over to a second node using SCSI persistent reservation to ensure only one
node at a time can write the databases. This would of course require hardware that supports
shared disks.

Is this what you meant by subprojects?

> Reliable standalone mode through redundant databases
> ----------------------------------------------------
>                 Key: ZOOKEEPER-1508
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1508
>             Project: ZooKeeper
>          Issue Type: New Feature
>         Environment: Single server with multiple disks or two node cluster with multiple
shared disks
>            Reporter: Bill Bridge
> Currently ZooKeeper requires 3 servers to provide both reliability and availability.
This is fine for large internet scale clusters, but there are lots of two node clusters that
could benefit from ZooKeeper.  There are also single server use cases where it is highly desirable
to have ZooKeeper survive a disk failure, but availability is not as important. 
> This feature would allow the configuration of multiple destinations for logs and snapshots.
A transaction is committed when a majority of the log writes complete successfully. If one
log gets an error on write, then it is taken offline until an administrator brings it online
or replaces it with a new destination. ZooKeeper continues to run as long as a quorum of disks
can be written.
> High availability can be provided with a two node cluster. When the ZooKeeper node dies,
the  disks are switched to the surviving node and a new ZooKeeper starts. Faster switch over
can be done if there is an observer already running in the new node.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message