[ https://issues.apache.org/jira/browse/HDFS-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ekanth Sethuramalingam updated HDFS-14317: ------------------------------------------ Description: The standby uses the following method to check if it is time to trigger edit log rolling on active. {code} /** * @return true if the configured log roll period has elapsed. */ private boolean tooLongSinceLastLoad() { return logRollPeriodMs >= 0 && (monotonicNow() - lastLoadTimeMs) > logRollPeriodMs ; } {code} In doTailEdits(), lastLoadTimeMs is updated when standby is able to successfully tail any edits {code} if (editsLoaded > 0) { lastLoadTimeMs = monotonicNow(); } {code} The default configuration for {{dfs.ha.log-roll.period}} is 120 seconds and {{dfs.ha.tail-edits.period}} is 60 seconds. With in-progress edit log tailing enabled, tooLongSinceLastLoad() will almost never return true resulting in edit logs not rolled for a long time until this configuration {{dfs.namenode.edit.log.autoroll.multiplier.threshold}} takes effect. [In our deployment, this resulted in in-progress edit logs getting deleted. The sequence of events is that standby was able to checkpoint twice while the in-progress edit log was growing on active. When the NNStorageRetentionManager decided to cleanup old checkpoints and edit logs, it cleaned up the in-progress edit log from active and QJM (as the txnid on in-progress edit log was older than the 2 most recent checkpoints) resulting in irrecoverably losing a few minutes worth of metadata]. was: The standby uses the following method to check if it is time to trigger edit log rolling on active. {{/**}} \{{ * @return true if the configured log roll period has elapsed.}} \{{ */}} {{private boolean tooLongSinceLastLoad() {}} \{{ return logRollPeriodMs >= 0 && }} {{ (monotonicNow() - lastLoadTimeMs) > logRollPeriodMs ;}} {{}}} In doTailEdits(), lastLoadTimeMs is updated when standby is able to successfully tail any edits {{if (editsLoaded > 0) {}} {{ lastLoadTimeMs = monotonicNow();}} {{}}} The default configuration for {{dfs.ha.log-roll.period}} is 120 seconds and {{dfs.ha.tail-edits.period}} is 60 seconds. With in-progress edit log tailing enabled, tooLongSinceLastLoad() will almost never return true resulting in edit logs not rolled for a long time until this configuration {{dfs.namenode.edit.log.autoroll.multiplier.threshold}} takes effect. [In our deployment, this resulted in in-progress edit logs getting deleted. The sequence of events is that standby was able to checkpoint twice while the in-progress edit log was growing on active. When the NNStorageRetentionManager decided to cleanup old checkpoints and edit logs, it cleaned up the in-progress edit log from active and QJM (as the txnid on in-progress edit log was older than the 2 most recent checkpoints) resulting in irrecoverably losing a few minutes worth of metadata]. > Standby does not trigger edit log rolling when in-progress edit log tailing > is enabled > -------------------------------------------------------------------------------------- > > Key: HDFS-14317 > URL: https://issues.apache.org/jira/browse/HDFS-14317 > Project: Hadoop HDFS > Issue Type: Bug > Affects Versions: 2.9.0, 3.0.0 > Reporter: Ekanth Sethuramalingam > Assignee: Ekanth Sethuramalingam > Priority: Critical > > The standby uses the following method to check if it is time to trigger edit > log rolling on active. > {code} > /** > * @return true if the configured log roll period has elapsed. > */ > private boolean tooLongSinceLastLoad() { > return logRollPeriodMs >= 0 && > (monotonicNow() - lastLoadTimeMs) > logRollPeriodMs ; > } > {code} > In doTailEdits(), lastLoadTimeMs is updated when standby is able to > successfully tail any edits > {code} > if (editsLoaded > 0) { > lastLoadTimeMs = monotonicNow(); > } > {code} > The default configuration for {{dfs.ha.log-roll.period}} is 120 seconds and > {{dfs.ha.tail-edits.period}} is 60 seconds. With in-progress edit log tailing > enabled, tooLongSinceLastLoad() will almost never return true resulting in > edit logs not rolled for a long time until this configuration > {{dfs.namenode.edit.log.autoroll.multiplier.threshold}} takes effect. > [In our deployment, this resulted in in-progress edit logs getting deleted. > The sequence of events is that standby was able to checkpoint twice while the > in-progress edit log was growing on active. When the > NNStorageRetentionManager decided to cleanup old checkpoints and edit logs, > it cleaned up the in-progress edit log from active and QJM (as the txnid on > in-progress edit log was older than the 2 most recent checkpoints) resulting > in irrecoverably losing a few minutes worth of metadata]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org