edits日志不删除现象排查

背景

最近自己搭建了一套 hadoop 3.3.1 的集群用于自己的股票指标计算,发现 secondary namenode 虽然把 edits 日志合并到了最新的 image,但是历史的 edits 日志并不会删除,导致在元数据目录 ls 查看文件时,有很多 edits 文件。

图片

图片

从上图可以看到,当前时间日期为 10.8 号,但是 8.18 的 edits 日志依然没有删除.

图片

通过统计文件数,可以看到一共有 10009 个文件,扣除 VERSION,seen_txid 等 7 个非 edits 文件,一共有 10002 个日志文件。

而 edits 太多,会影响到 hadoop 的启动。

根据网上相关的文章,在合并完后 edits 应该会删除,这一现象和了解到的只是相悖,本文为了了解 edits 啥时候会删除。

元数据各文件详解

从上图的元数据目录查看,可以看到文件分为以下 6 类

  • edits_000xxxx-000xxxx
  • edits_inprogress_000xxxx
  • fsimage_000xxx
  • fsimage_000xxx.md5
  • seen.txid
  • VERSION
    那么,每种文件的作用和功能是什么呢?

具体可以参考本人之前文章: hdfs 中元数据 fsimage,edits详解

edits 文件什么时候删除?

那么,edits 文件具体什么时候删除了,这时候就要从源码入手了。

edit log 删除源码探究

1、已知线索:dfs.namenode.name.dir

我们知道,写 edits 日志需要只要目标文件的目录,而 edits 日志的存储目录是由 hdfs-site.xml 文件中的

dfs.namenode.name.dir
默认值: file://${hadoop.tmp.dir}/dfs/name

进行指定的,那么这个配置就可以作为线索进行搜索,在 hadoop 源码中进行搜索 dfs.namenode.name.dir
图片

可以看到在 HdfsClientConfigKeys 类中,使用了变量 DFS_NAMENODE_NAME_DIR_KEY来引用 dfs.namenode.name.dir

2、查看使用 DFS_NAMENODE_NAME_DIR_KEY 的代码

使用 idea 的 find usage 功能,来查看 DFS_NAMENODE_NAME_DIR_KEY 被哪些类使用