[ https://issues.apache.org/jira/browse/HDFS-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044047#comment-13044047 ]
Todd Lipcon commented on HDFS-2026: ----------------------------------- I agree with that as well. I'll file a new JIRA for it -- I feel like it's out of scope for this one. > 1073: 2NN needs to handle case of reformatted NN better > ------------------------------------------------------- > > Key: HDFS-2026 > URL: https://issues.apache.org/jira/browse/HDFS-2026 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: name-node > Affects Versions: Edit log branch (HDFS-1073) > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Priority: Critical > Fix For: Edit log branch (HDFS-1073) > > > Currently in the 1073 branch, the following steps ends up with a very > confused 2NN: > - format NN, run NN > - start 2NN, perform some checkpoints > - reformat NN, start NN on new namespace > - restart same 2NN > The 2NN currently saves the new VERSION info into its local storage directory > but doesn't clear out the old checkpoint or edits files. This is obviously > wrong and might lead to a corrupt checkpoint getting uploaded. > If the 2NN has storage directories with VERSION info, and connects to an NN > with different VERSION info, there are two alternatives: > a) refuse to perform any checkpoints until the operator issues a > "secondarynamenode -format" command (this is similar to how the > backupnode/checkpointnode works) > b) clear the current contents of the storage directory and save the new NN's > VERSION info. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira