前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >0482-HDFS上一次检查点异常分析

0482-HDFS上一次检查点异常分析

作者头像
Fayson
发布2018-12-27 14:23:50
1.6K0
发布2018-12-27 14:23:50
举报
文章被收录于专栏:Hadoop实操Hadoop实操

温馨提示:如果使用电脑查看图片不清晰,可以使用手机打开文章单击文中的图片放大查看高清原图。

Fayson的github: https://github.com/fayson/cdhproject

提示:代码块部分可以左右滑动查看噢

1

问题重现

1.通过Ambari界面看到HDFS有如下警告

点开来具体查看发现Active NameNode和Stanby NameNode都有上一次检查点的告警。

2

问题解决

1.执行以下命令手动保存一次HDFS的检查点

代码语言:javascript
复制
[root@ip-172-31-4-109 ~]# sudo -u hdfs hdfs dfsadmin -safemode enter
Safe mode is ON in ip-172-31-4-109.ap-southeast-1.compute.internal/172.31.4.109:8020
Safe mode is ON in ip-172-31-1-163.ap-southeast-1.compute.internal/172.31.1.163:8020
[root@ip-172-31-4-109 ~]# sudo -u hdfs hdfs dfsadmin -saveNamespace
Save namespace successful for ip-172-31-4-109.ap-southeast-1.compute.internal/172.31.4.109:8020
Save namespace successful for ip-172-31-1-163.ap-southeast-1.compute.internal/172.31.1.163:8020
[root@ip-172-31-4-109 ~]# sudo -u hdfs hdfs dfsadmin -safemode leave
Safe mode is OFF in ip-172-31-4-109.ap-southeast-1.compute.internal/172.31.4.109:8020
Safe mode is OFF in ip-172-31-1-163.ap-southeast-1.compute.internal/172.31.1.163:8020
[root@ip-172-31-4-109 ~]#

2.在Ambari界面上检查警告已经消失

3

总结

1.首先通过Ambari查看以下两个参数:

dfs.namenode.checkpoint.period

--两次检查点创建之间的固定时间间隔,默认3600,即1小时。

dfs.namenode.checkpoint.txns

--未检查的事务数量。若没检查事务数达到这个值,也触发一次checkpoint,1,000,000。

一个是21600秒,即6小时,一个是默认值100万。

2.Fayson在执行手动保存检查点之前,看了下Active NameNode和Stanby NameNode上保存的fsimage的checkpoint的情况如下:

符合预期都是在之前6小时就保存了一次checkpoint

3.手动保存checkpoint后,发现最旧的一条被冲掉了,是因为这个受另外一个参数影响:

dfs.namenode.num.checkpoints.retained

--在namenode上保存的fsimage的数目,超出的会被删除。默认保存2个。

4.Fayson的集群环境因为几天没开机了,所以导致HDFS会有这个警告(可能是之前直接关服务器导致),理论如果过6小时,应该可以自动恢复,当然你的集群如果允许停机一会,也可以按照本文描述的方式手动进行保存检查点。

4

附录:checkpoint的过程

以下内容完全转载自网络:

代码语言:javascript
复制
https://blog.csdn.net/amber_amber/article/details/47003589

HDFS将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时,系统会先加载fsimage,然后逐个执行所有Edits文件中的每一条操作,来获取完整的文件系统元数据。

4.1

Edits&fsimage文件

HDFS的存储元数据是由fsimage和edits文件组成。fsimage存放上次checkpoint生成的文件系统元数据,Edits存放文件系统操作日志。checkpoint的过程,就是合并fsimage和Edits文件,然后生成最新的fsimage的过程。

1.Edits文件: 在配置了HA的hadoop2.x版本中,active namenode会及时把HDFS的修改信息(创建,修改,删除等)写入到本地目录,和journalnode上的Edits文件,每一个操作以一条数据的形式存放。Edits文件默认每2分钟产生一个。正在写入的Edits文件以edits_inprogress_*格式存在。

2.fsimage文件: fsimage里保存的是HDFS文件系统的元数据信息。每次checkpoint的时候生成一个新的fsimage文件,fsimage文件同步保存在active namenode上和standby namenode上。是在standby namenode上生成并上传到active namenode上的。

4.2

checkpoint过程

配置了HA的HDFS中,有active和standby namenode两个namenode节点。他们的内存中保存了一样的集群元数据信息,这个后续我会详细用一篇文章介绍HA,所以这里就不多说了。因为standby namenode已经将集群状态存储在内存中了,所以创建检查点checkpoint的过程只需要从内存中生成新的fsimage。

详细过程如下: (standby namenode=SbNN, active namenode=ANN)

1. SbNN查看是否满足创建检查点的条件:

(1) 距离上次checkpoint的时间间隔 >= ${dfs.namenode.checkpoint.period}

(2) Edits中的事务条数达到${dfs.namenode.checkpoint.txns}限制

这两个条件任何一个被满足了,就触发一次检查点创建。

2. SbNN将内存中当前的状态保存成一个新的文件,命名为fsimage.ckpt_txid。其中txid是最后一个edit中的最后一条事务的ID(transaction ID)。然后为该fsimage文件创建一个MD5文件,并将fsimage文件重命名为fsimage_txid。

3. SbNN向active namenode发送一条HTTP GET请求。请求中包含了SbNN的域名,端口以及新fsimage的txid。

4. ANN收到请求后,用获取到的信息反过来向SbNN再发送一条HTTP GET请求,获取新的fsimage文件。这个新的fsimage文件传输到ANN上后,也是先命名为fsimage.ckpt_txid,并为它创建一个MD5文件。然后再改名为fsimage_txid。fsimage过程完成。

参考:

https://blog.csdn.net/amber_amber/article/details/47003589

https://community.hortonworks.com/questions/36634/namenode-last-checkpoint-script-alert-definition-d.html

提示:代码块部分可以左右滑动查看噢

为天地立心,为生民立命,为往圣继绝学,为万世开太平。 温馨提示:如果使用电脑查看图片不清晰,可以使用手机打开文章单击文中的图片放大查看高清原图。

推荐关注Hadoop实操,第一时间,分享更多Hadoop干货,欢迎转发和分享。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-12-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Hadoop实操 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档