当它这样说时，secondary namenode每小时检查一次（fs.checkpoint.period，以秒为单位），或者如果编辑日志已达到64 mb（fs.checkpoint.size，以字节为单位），则更快？这到底是什么意思？据我所知，编辑日志存储在本地文件磁盘中。
zhte4eai1#
hdfs元数据可以认为由两部分组成：基本文件系统表（存储在名为 fsimage )以及编辑日志，其中列出对基表所做的更改（存储在名为 edits ). 检查点是一个协调的过程 fsimage 与 edits 制作新版本的 fsimage . 这样做有两个好处：一个更新版本的 fsimage ，以及截断的编辑日志。 fs.checkpoint.period 控制触发此对帐的频率。 3600 意味着每小时 fsimage 将更新并截断编辑日志。checkpiont并不便宜，所以在频繁运行checkpiont和让编辑日志增长过大之间有一个平衡点。假设集群中使用典型的文件系统，应该设置此参数以获得良好的平衡。 fs.checkpoint.size 是大小阈值，如果 edits ，将触发一个立即检查点，而不管上次检查点经过多长时间。在文件系统元数据异常繁忙的写入流量下，编辑日志变得太大，这是一种保险。
fsimage
edits
fs.checkpoint.period
3600
fs.checkpoint.size
idfiyjo82#
namenode在hdfs中维护名称空间。所有datanode文件元数据都存储在namenode的editlog和fsimage中。fsimage是给定时间的hdfs文件系统的映像，它是集群上发生的所有更改的累积。editlog包含最新的更改。检查点是将editlog合并到fsimage的过程。这个过程是资源密集型的，它会影响namenode上正在进行的请求。辅助namenode为hdsf namenode执行检查点。它向namenode发出http请求，获取最新的fsimage日志，并将其与editlogs中捕获的最新更改合并。使用合并的fsimage和editlog的主namenode请求和次namenode响应被截断。这是一个事件驱动的过程，其中事件是基于以下任何条件触发的：1）以秒为单位的特定时间段fs.checkpoint.period 2）editlog达到特定大小fs.checkpoint.size其中任何一个都可以在core-default.xml中配置。这应该根据可用的网络带宽以及指定时间内可能发生的变化的累积来设置为最佳。
2条答案
按热度按时间zhte4eai1#
hdfs元数据可以认为由两部分组成：基本文件系统表（存储在名为
fsimage)以及编辑日志，其中列出对基表所做的更改（存储在名为edits). 检查点是一个协调的过程fsimage与edits制作新版本的fsimage. 这样做有两个好处：一个更新版本的fsimage，以及截断的编辑日志。fs.checkpoint.period控制触发此对帐的频率。3600意味着每小时fsimage将更新并截断编辑日志。checkpiont并不便宜，所以在频繁运行checkpiont和让编辑日志增长过大之间有一个平衡点。假设集群中使用典型的文件系统，应该设置此参数以获得良好的平衡。fs.checkpoint.size是大小阈值，如果edits，将触发一个立即检查点，而不管上次检查点经过多长时间。在文件系统元数据异常繁忙的写入流量下，编辑日志变得太大，这是一种保险。idfiyjo82#
namenode在hdfs中维护名称空间。所有datanode文件元数据都存储在namenode的editlog和fsimage中。fsimage是给定时间的hdfs文件系统的映像，它是集群上发生的所有更改的累积。editlog包含最新的更改。检查点是将editlog合并到fsimage的过程。这个过程是资源密集型的，它会影响namenode上正在进行的请求。
辅助namenode为hdsf namenode执行检查点。它向namenode发出http请求，获取最新的fsimage日志，并将其与editlogs中捕获的最新更改合并。使用合并的fsimage和editlog的主namenode请求和次namenode响应被截断。
这是一个事件驱动的过程，其中事件是基于以下任何条件触发的：1）以秒为单位的特定时间段fs.checkpoint.period 2）editlog达到特定大小fs.checkpoint.size
其中任何一个都可以在core-default.xml中配置。这应该根据可用的网络带宽以及指定时间内可能发生的变化的累积来设置为最佳。