博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
HDFS之checkpoint机制---大数据分析学习笔记5
阅读量:3905 次
发布时间:2019-05-23

本文共 1172 字,大约阅读时间需要 3 分钟。

Checkpoint(检查点):

HDFS这样的分布式文件系统,对文件数据的修改不是直接写回到磁盘的,很多操作是先缓存到内存的Buffer中,当遇到一个检查点Checkpoint时,系统会强制将内存中的数据写回磁盘,当然此时才会记录日志,从而产生持久的修改状态。

1.Namenode上面有些什么数据:

笔记2中提到namenode管理结点主要有下面两类文件
edits:HDFS操作的日志记录,没此对HDFS进行修改操作后,都会往edits中记录一条日志;
fsimage:HDFS中命名空间、数据块分布、文件属性等信息都存放在fsimage中;
注:只有在每次启动Namenode时,才会把edits中的操作增加到fsimage中,并且把edits清空。
所以fsimage总是记录启动Namenode时的状态,而edits在每次启动时也是空的,它只记录本次启动后的操作日志。

2.checkpoint触发的条件

在配置文件中有两个参数:
fs.checkpoint.period:设置两次相邻checkpoint之间的时间间隔,默认是1小时;
fs.checkpoint.size:设置一个edits文件大小的阈值,达到这个阈值,就强制执行一此checkpoint(即使此时没有达到period的时限),默认为64MB。

3.Checkpoint执行过程

Chekpoint主要干的事情是,将Namenode中的edits和fsimage文件拷贝到Second Namenode上,然后将edits中的操作与fsimage文件merge以后形成一个新的fsimage,这样不仅完成了对现有Namenode数据的备份,而且还产生了持久化操作的fsimage。最后一步,Second Namenode需要把merge后的fsimage文件upload到Namenode上面,完成Namenode中fsimage的更新。
当Namenode发生故障丢失元数据后,可以利用Second Namenode进行导入恢复:
(1)在Namenode的节点上面创建dfs.name.dir指定的目录;
(2)指定配置文件中的fs.checkpoint.dir(应该是hdfs-site.xml文件);
(3)启动Namenode时带上选项 -importCheckpoint。
(4)Namenode首先会将fs.checkpoint.dir中的文件拷贝到dfs.name.dir中,如果此时dfs.name.dir中已经包含了合法的fsimage文件(也就是Namenode没有发生元数据丢失却执行了导入操作),那么Namenode就会执行失败。否则,Namenode会检测导入的fsimage文件是否与文件系统中的数据一致,若一致则成功完成导入恢复。

转载地址:http://arqen.baihongyu.com/

你可能感兴趣的文章
Linux 路由 学习笔记 之三 路由查找流程分析
查看>>
LINUX IP 路由实现
查看>>
快速重传与快速恢复算法
查看>>
TCP重传定时器
查看>>
CentOS 6.3 - 安装 Nginx 1.2.7(yum源)
查看>>
shell中trap捕获信号
查看>>
关于Linux Shell的信号trap功能你必须知道的细节
查看>>
Linux原始套接字实现分析
查看>>
CENTOS 6.5 配置YUM安装NGINX
查看>>
#ifdef DEBUG的理解
查看>>
Linux 任务控制的几个技巧( &, [ctrl]-z, jobs, fg, bg, kill)
查看>>
慧眼云:基于云计算和大数据分析的主动防御实践
查看>>
58集团监控业务实践:将网站运行信息透明化
查看>>
给Django用户的SQLAlchemy介绍
查看>>
consul http api
查看>>
如何定位问题
查看>>
使用火焰图分析CPU性能回退问题
查看>>
openresty lua zlib整合安装 让lua支持解压服务端压缩过的数据
查看>>
Nginx与Gzip请求
查看>>
最佳日志实践(v2.0)
查看>>