[
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
