[ 
https://issues.apache.org/jira/browse/HDFS-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159051#comment-13159051
 ] 

Todd Lipcon commented on HDFS-1975:
-----------------------------------

I chatted with ATM offline about this. In our opinion it makes the most sense 
to commit this patch pretty much as-is, even though we know there are some 
issues as described above. Then, we can open separate follow-on JIRAs for each 
of the distinct issues:
- one JIRA for dealing with the standby losing block locations because OP_ADD 
and OP_CLOSE replace the BlockInfos
- one JIRA to make the standby not manage replication and invalidation queues 
until it enters active mode
- one JIRA to figure out if we need to track txids through the NN<->DN 
messaging instead of just using the genstamps as Jitendra has done in the patch 
here.

Having this basic tailing infrastructure committed will let us start to 
investigate and fix the above issues in parallel and make faster progress.

Agreed?
                
> HA: Support for sharing the namenode state from active to standby.
> ------------------------------------------------------------------
>
>                 Key: HDFS-1975
>                 URL: https://issues.apache.org/jira/browse/HDFS-1975
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>            Reporter: Suresh Srinivas
>            Assignee: Jitendra Nath Pandey
>         Attachments: HDFS-1975-HA.2.patch, HDFS-1975-HA.patch, 
> HDFS-1975-HDFS-1623.patch, HDFS-1975-HDFS-1623.patch, 
> HDFS-1975-HDFS-1623.patch, hdfs-1975.txt, hdfs-1975.txt
>
>
> To enable hot standby namenode, the standby node must have current 
> information for - namenode state (image + edits) and block location 
> information. This jira addresses keeping the namenode state current in the 
> standby node. To do this, the proposed solution in this jira is to use a 
> shared storage to store the namenode state. 
> Note one could also build an alternative solution by augmenting the backup 
> node. A seperate jira could explore this.

--
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

        

Reply via email to