[
https://issues.apache.org/jira/browse/HDFS-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049203#comment-15049203
]
Kihwal Lee commented on HDFS-9533:
----------------------------------
It turned out a standby namenode was bootstrapped.
This is from {{BootstrapStandby#downloadImage()}} or {{doRun()}} in 2.6.
{code:java}
// 1
long curTxId = proxy.getTransactionID();
// 2
image.initEditLog(StartupOption.REGULAR);
// 3
image.getStorage().writeTransactionIdFileToStorage(curTxId);
{code}
(1) gets the current txid from the active node via rpc. (2) causes
{{editLog.initSharedJournalsForRead()}} to be called and the {{NNStorage}} will
contain the shared edits directory after that. When (3) is called, the txid
obtained in (1) will be written to the shared edits directory.
No matter what the intention of this code was, the shared edits directory
shouldn't be altered by non-active namenode.
> seen_txid in the shared edits directory is modified during bootstrapping
> ------------------------------------------------------------------------
>
> Key: HDFS-9533
> URL: https://issues.apache.org/jira/browse/HDFS-9533
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: ha, namenode
> Affects Versions: 2.6.0
> Reporter: Kihwal Lee
>
> The last known transaction id is stored in the seen_txid file of all known
> directories of a NNStorage when starting a new edit segment. However, we have
> seen a case where it contains an id that falls in the middle of an edit
> segment. This was the seen_txid file in the sahred edits directory. The
> active namenode's local storage was containing valid looking seen_txid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
