胡旻整理 转载请注明
最近团队在整理一些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; } } } } } |
上图为当最后一次往journalNode写入的TxId,和下图值类似
还有如下两项,用于设置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 条评论