文件系统映像 ( fsimage ) 和 编辑日志 ( edits )
当创建或移动文件时 ,会把操作记录在编辑日志中 ,NameNode 在内存中维护文件系统的元数据 ,当编辑日志被修改时 ,相关的元数据信息也同步更新
每个 fsimage 文件都是文件系统元数据的一个完整的永久性检查点 ,并非每个写操作都会更新该文件 ,因为 fsimage 可能会很大 ,如果频繁执行写操作 ,会使系统运行极为缓慢
如果 NameNode 发生故障时 ,最近的 fsimage 文件将被载入到内存以重构元数据最近的状态 ,再从相关点开始向前执行编辑日志中记录的每个事务
编辑日志会无限增长 ,执行这些事务时 NameNode 的重启操作会比较慢 解决方案就是使用 SecondNameNode
流程 :
- SecondNameNode 请求 NameNode 停止使用正在进行的 edits 文件 ,这样新的编辑操作记录到一个新文件中 ,主 Namenode 还会更新所有存储目录中的 see_txid 文件
- SecondNameNode 从主 NamoNode 获取最近的 fsimage 和 edits 文件 ( 采用 HTTP GET )
- SecondNameNode 将 fsimage 文件载入内存 ,逐一执行 edits 文件中的事务 ,创建新的合并后的 fsimage 文件
- SecondNameNode 将新的 fsimage 文件发送回主 NameNode ( 使用 HTTP PUT ) ,主 NameNode 将其保存为临时的 .ckpt 文件
- NameNode 重新命名临时的 fsimage 文件 ,便于日后使用
两个相关参数
dfs.namenode.checkpoint.check.period = 60 # 检查触发条件是否满足的频率
dfs.namenode.checkpoint.dir = 文件存储位置
HDFS的安全模式在做什么?
NameNode 启动时 ,首先将映像文件 ( fsimage ) 载入内存 ,并执行编辑日志 ( edits ) 中的各项编辑操作 ,一旦内存中成功建立文件系统元数据映像 ,则创建一个新的 fsimage 文件 ( 不借助 SecondNameNode )
和一个空的编辑日志 ,这个过程中 NameNode 运行在安全模式 ,意味着 NameNode 的文件系统对于客户端来说是只读的
检查当前可用 Block 块 占比 ,如果达不到配置文件所设置的占比数 ,则处于安全模式
检查 是否有 DataNode 没有启动
hdfs fsck / -delete 删除错误的块
文件系统检查工具 hdfs fsck /
三个datanode中当有一个datanode出现错误时会怎样
Namenode会通过心跳机制感知到datanode下线
会将这个datanode上的block块在集群中重新复制一份，恢复文件的副本数量
会引发运维团队快速响应，派出同事对下线datanode进行检测和修复，然后重新上线