[
https://issues.apache.org/jira/browse/HDFS-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298235#comment-14298235
]
Harsh J commented on HDFS-7501:
-------------------------------
[~daryn] - The metric goes negative at the standby after the first checkpoint
and continues going negative until it is in active mode again. The reason is
that the getEditLog().getLastWrittenTxId() freezes in standby mode where no
local edit logs are written anymore, and only the edit log tailer has the txid
tracking info. We could switch to querying that - would that make sense to do
just when we are in standby mode.
We could expose lastLoadedTxnId in the EditLogTailer, for example.
Sorry on delay in responding.
> TransactionsSinceLastCheckpoint can be negative on SBNs
> -------------------------------------------------------
>
> Key: HDFS-7501
> URL: https://issues.apache.org/jira/browse/HDFS-7501
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.5.0
> Reporter: Harsh J
> Assignee: Gautam Gopalakrishnan
> Priority: Trivial
> Attachments: HDFS-7501-2.patch, HDFS-7501.patch
>
>
> The metric TransactionsSinceLastCheckpoint is derived as FSEditLog.txid minus
> NNStorage.mostRecentCheckpointTxId.
> In Standby mode, the former does not increment beyond the loaded or
> last-when-active value, but the latter does change due to checkpoints done
> regularly in this mode. Thereby, the SBN will eventually end up showing
> negative values for TransactionsSinceLastCheckpoint.
> This is not an issue as the metric only makes sense to be monitored on the
> Active NameNode, but we should perhaps just show the value 0 by detecting if
> the NN is in SBN form, as allowing a negative number is confusing to view
> within a chart that tracks it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
