Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 30 Aug 2012 05:48:07 +1100 (NCT)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <889937086.13201.1346266087742.JavaMail.jiratomcat@arcas>
In-Reply-To: <2102433793.8672.1346188388294.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HDFS-3863) QJM: track last "committed" txid
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon commented on HDFS-3863:
-----------------------------------

BTW, I forgot to address this comment:

{quote}However, imagine a stupid administrator replaces JN2 and JN3 with some new machines. Since JN1 is far behind, it doesn't know about the journal number committed by JN2 and JN3. It passes the check.
{quote}

In the case that the admin replaces a majority of nodes, then the NN would refuse to start up because they would throw "JournalNotFormattedException". See the discussion on https://issues.apache.org/jira/browse/HDFS-3743
                
> QJM: track last "committed" txid
> --------------------------------
>
>                 Key: HDFS-3863
>                 URL: https://issues.apache.org/jira/browse/HDFS-3863
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: ha
>    Affects Versions: QuorumJournalManager (HDFS-3077)
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>
> Per some discussion with [~stepinto] [here|https://issues.apache.org/jira/browse/HDFS-3077?focusedCommentId=13422579&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13422579], we should keep track of the "last committed txid" on each JournalNode. Then during any recovery operation, we can sanity-check that we aren't asked to truncate a log to an earlier transaction.
> This is also a necessary step if we want to support reading from in-progress segments in the future (since we should only allow reads up to the commit point)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira