Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Fri, 3 Jun 2011 20:42:47 +0000 (UTC)
From: "Sanjay Radia (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1238897460.67137.1307133767329.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <534699613.64473.1307054867450.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-2026) 1073: 2NN needs to handle case of
 reformatted NN better
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sanjay Radia commented on HDFS-2026:
------------------------------------

I also prefer option 1.

Shouldn't we be using the namespaceid to address this issue.
BTW we have the same problem in alternate solution (after 1073) where the fsimage is simply copied over the NN's dirs. (Good news is that that no images are deleted as part of that.)


> 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