[
https://issues.apache.org/jira/browse/HDFS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229592#comment-13229592
]
Todd Lipcon commented on HDFS-3077:
-----------------------------------
bq. The flip side of this though is that if a ZK issue were identified it could
be fixed and redeployed w/o requiring a re-release of Hadoop. ZK blocker issues
are typically turned around quite rapidly, while rare on the stable codeline
it's usually on order of days to a week.
That's true of ZK issues. But is the same true of BK, which is marked "contrib"
and isn't deployed in production anywhere except for one org AFAIK? Looking at
recent commits to the BK tree, it's an awful lot of bug fixes relating to the
indexing code that allows multiple logs to be interleaved, etc -- issues
stemming from its generality.
> Quorum-based protocol for reading and writing edit logs
> -------------------------------------------------------
>
> Key: HDFS-3077
> URL: https://issues.apache.org/jira/browse/HDFS-3077
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: ha, name-node
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
>
> Currently, one of the weak points of the HA design is that it relies on
> shared storage such as an NFS filer for the shared edit log. One alternative
> that has been proposed is to depend on BookKeeper, a ZooKeeper subproject
> which provides a highly available replicated edit log on commodity hardware.
> This JIRA is to implement another alternative, based on a quorum commit
> protocol, integrated more tightly in HDFS and with the requirements driven
> only by HDFS's needs rather than more generic use cases. More details to
> follow.
--
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
