[
https://issues.apache.org/jira/browse/HDFS-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244410#comment-13244410
]
Todd Lipcon commented on HDFS-3092:
-----------------------------------
bq. This is what I was thinking - when roll is called from NN, it includes the
version # from journalList ZK node. It gets recorded in the start segment
transaction in the editlog. Does that work? Did I understand your comment
correctly?
Yes, that solves the problem, but then requires that the recovery protocol open
up and read the edits out of the logs. It also leaks the edits storage
mechanism into the edits contents, so I don't think it's quite the right design.
The solution I'm using in HDFS-3077 is to keep an extra file in the edits
directory which includes the version number. During recovery, edits-in-progress
on a logger whose version number is out of date with respect to the others can
be removed.
The thing is, once you've implemented all of this, I don't think your solution
is any less complex than the one in HDFS-3077 :)
> Enable journal protocol based editlog streaming for standby namenode
> --------------------------------------------------------------------
>
> Key: HDFS-3092
> URL: https://issues.apache.org/jira/browse/HDFS-3092
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: ha, name-node
> Affects Versions: 0.24.0, 0.23.3
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Attachments: MultipleSharedJournals.pdf
>
>
> Currently standby namenode relies on reading shared editlogs to stay current
> with the active namenode, for namespace changes. BackupNode used streaming
> edits from active namenode for doing the same. This jira is to explore using
> journal protocol based editlog streams for the standby namenode. A daemon in
> standby will get the editlogs from the active and write it to local edits. To
> begin with, the existing standby mechanism of reading from a file, will
> continue to be used, instead of from shared edits, from the local edits.
--
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
