humidy
作者humidy2015-09-08 10:35
信息分析/架构师, 某公司

hadoop_2关于元数据fsimage 和edits的那些事

字数 8132阅读 3236评论 0赞 1

胡旻整理 转载请注明

最近团队在整理一些Hadoop版本的自动化运维的经验,在运行hadoop 2版本过程中,一个小伙子发现${dfs.namenode.name.dir}/current目录下的fsimage_*只有2个,而edits_*文件越来越多。

故整理一下相关配置。

在hadoop_2中关于fsimage和editlogs的相关配置有如下几项:

<property>

  <name>dfs.namenode.checkpoint.period</name>

  <value>3600</value>

  <description>两次连续的检查点之间的最大的时间间隔,缺省值是1小时  </description>

</property>

<property>

  <name>dfs.namenode.checkpoint.check.period</name>

  <value>60</value>

  <description>监测点拉取主控节点,查询未检查的事务数目的间隔时间</description>

</property>

上述参数解释如下:

在Standby NameNode中会一直维护着一个叫CheckpointerThread的线程,这个线程调用StandbyCheckpointer类去每隔1000*Math.min(checkpointCheckPeriod,checkpointPeriod)秒检测一次是否要将fsimage和从journalNode同步过来的edits做一次合并操作,其中checkpointCheckPeriod由hdfs-site.xml中的dfs.namenode.checkpoint.period 配置,checkpointPeriod则有hdfs-site.xml中的dfs.namenode.checkpoint.check.period配置。

 

其中具体什么条件才符合合并条件,我们就看看看StandbyCheckpointer类的do work方法,看我的注释就一目了然了:

private void doWork() {

      // Reset checkpoint time so that we don't always checkpoint

      // on startup.

      lastCheckpointTime = now();

      while (shouldRun) {

        try {

        //每隔1000*Math.min(checkpointCheckPeriod, checkpointPeriod)秒检测一次是否要将fsimage和从journalNode同步过来的edits做一次合并操作

    Thread.sleep(1000 * checkpointConf.getCheckPeriod());

        } catch (InterruptedException ie) {

        }

        if (!shouldRun) {

          break;

        }

        try {

          // We may have lost our ticket since last checkpoint, log in again, just in case

          if (UserGroupInformation.isSecurityEnabled()) {

       UserGroupInformation.getCurrentUser().checkTGTAndReloginFromKeytab();

          }

          long now = now();

          //获得最后一次往journalNode写入的TxId(这个可以在namenode日志或者50070界面可以看到)和最近一次做Checkpoint的TxId的差值

          long uncheckpointed = countUncheckpointedTxns();

          long secsSinceLast = (now - lastCheckpointTime)/1000;

          boolean needCheckpoint = false;

          //第一种符合合并的情况:当最后一次往journalNode写入的TxId(这个可以在namenode日志或者50070界面可以看到)

          //和最近一次做Checkpoint的TxId的差值大于或者等于dfs.namenode.checkpoint.txns配置的数量(默认1000000)时做一次合并

          if (uncheckpointed >= checkpointConf.getTxnCount()) {

            LOG.info("Triggering checkpoint because there have been " +

                uncheckpointed + " txns since the last checkpoint, which " +

                "exceeds the configured threshold " +

                checkpointConf.getTxnCount());

            needCheckpoint = true;

          }

          //第二种符合合并的情况:当时间间隔大于或者等于dfs.namenode.checkpoint.period配置的时间时做合并

          else if (secsSinceLast >= checkpointConf.getPeriod()) {

            LOG.info("Triggering checkpoint because it has been " +

                secsSinceLast + " seconds since the last checkpoint, which " +

                "exceeds the configured interval " + checkpointConf.getPeriod());

            needCheckpoint = true;

          }

          synchronized (cancelLock) {

            if (now < preventCheckpointsUntil) {

              LOG.info("But skipping this checkpoint since we are about to failover!");

              canceledCount++;

              continue;

            }

            assert canceler == null;

            canceler = new Canceler();

          }

          if (needCheckpoint) {

            doCheckpoint();

            lastCheckpointTime = now;

          }

        } catch (SaveNamespaceCancelledException ce) {

          LOG.info("Checkpoint was cancelled: " + ce.getMessage());

          canceledCount++;

        } catch (InterruptedException ie) {

          // Probably requested shutdown.

          continue;

        } catch (Throwable t) {

          LOG.error("Exception in doCheckpoint", t);

        } finally {

          synchronized (cancelLock) {

            canceler = null;

          }

        }

      }

    }

  }

11.png

上图为当最后一次往journalNode写入的TxId,和下图值类似

12.png

 

还有如下两项,用于设置fsimage和edit log保存的记录数,默认保存2份fsimge和1000000份edits日志信息。

<property>

  <name>dfs.namenode.num.checkpoints.retained</name>

  <value>2</value>

  <description>保留的元数据image文件数目,默认是2</description>

</property>

 

<property>

  <name>dfs.namenode.num.extra.edits.retained</name>

  <value>1000000</value>

  <description>保留的元数据edits文件数目,默认是1百万

  通常1 百万的 edits 大小在几百万到1G,建议值:2200,约3天的

 

  注:除最小的必须的editlog之外,额外保留的editlog文件数量。这是有用的,可以用于审核目的,或者HA设置一个远程Standby节点并且有时可能离线时,都需要保留一个较长的backlog。

典型的,每个edit大约几百字节,默认的1百万editlog大约有百兆到1G。注意:早先的extra edits文件可能操作这里设置的值,因为还有其它选项,例如dfs.namenode.max.extra.edits.segments.retained

  </description>

</property>

<property>

  <name>dfs.namenode.max.extra.edits.segments.retained</name>

  <value>10000</value>

  <description>

extra edit日志文件segments的最大数量。除了用于NN重启时的最小edits文件之外。一个segments包含多个日志文件

  </description>

</property>

 

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广