Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Tue, 31 Jul 2012 18:16:35 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <2072335410.122669.1343758595168.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <238972383.119358.1343696794968.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (HDFS-3743) QJM: improve formatting behavior for
 JNs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell commented on HDFS-3743:
--------------------------------------

Not sure about the notion of automating an "unsafe startup" in the case the majority of JNs are unformatted. What if instead, it's possible to start up the NN in recovery mode and have it interactively suggest actions including initializing the unformatted JNs? Could summarize the most recent txn (or a few txns) of the available logs before asking which txid to choose as latest?
                
> QJM: improve formatting behavior for JNs
> ----------------------------------------
>
>                 Key: HDFS-3743
>                 URL: https://issues.apache.org/jira/browse/HDFS-3743
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>    Affects Versions: QuorumJournalManager (HDFS-3077)
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>
> Currently, the JournalNodes automatically format themselves when a new writer takes over, if they don't have any data for that namespace. However, this has a few problems:
> 1) if the administrator accidentally points a new NN at the wrong quorum (eg corresponding to another cluster), it will auto-format a directory on those nodes. This doesn't cause any data loss, but would be better to bail out with an error indicating that they need to be formatted.
> 2) if a journal node crashes and needs to be reformatted, it should be able to re-join the cluster and start storing new segments without having to fail over to a new NN.
> 3) if 2/3 JNs get accidentally reformatted (eg the mount point becomes undone), and the user starts the NN, it should fail to start, because it may end up missing edits. If it auto-formats in this case, the user might have silent "rollback" of the most recent 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