[
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
