secondnamenode界面没有checkpoint time，这是为啥？

大家好，目前遇到问题如下：
1.namenode在A机器上，但是检查发现fsimage和edits从这次启动后就未合并，fsimage依旧是第一次启动时候的日期，而且edits正在不断增加，现在目录文件数量已经累计了20多万了
2.在B机器上启动了secondnamenode，但是进入页面里，看不到checkpoint time的刷新，而且自己测试的环境用一样的配置是可以的
3.环境的不同，正式环境有kerberos，测试环境没有。

想问下大家，我snn上能看到fsimage跟edits合并，但是好像并没有更新到nn上进行同步，这是什么原因导致的？日志似乎看不到什么异常。是因为缺少或者错误的配置吗？

snn截图：

B机进入目录能看到fsimage和edits有合并，因为fsimage的日期在更新，且已经不是启动的时间了。

HawCHing 发表于 2017-1-3 15:41
B机进入目录能看到fsimage和edits有合并，因为fsimage的日期在更新，且已经不是启动的时间了。

Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢。

core-site.xml 配置文件中可以找下这个配置项：fs.checkpoint.period：单位秒，默认值3600，如果没有的话，可以配置下

muyannian 发表于 2017-1-3 16:03
Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage ...

我现在基本能确定B机所在的snn上有合并操作，但是它不会上传到A机的nn上，达到减少nn上edits的目的，这个不知道为什么。

qcbb001 发表于 2017-1-3 16:18
core-site.xml 配置文件中可以找下这个配置项：fs.checkpoint.period：单位秒，默认值3600，如果没有的话， ...

这个我实验了，好像没有这两个配置，还是会按默认的3600秒和1M来进行checkpoint，而且我刚发现好像hadoop1跟hadoop2的这个配置参数还是有区别的吗？
hadoop1用fs.checkpoint.period并不生效，而用hdfs-site.xml中的dfs.namenode.checkpoint.period  这个就能在web页面里生效，是这样吗？

还有我现在希望解决的是A机上的nn中 fsimage跟edits一直不合并的问题，怕太多了导致下一次重启会花费很久时间

HawCHing 发表于 2017-1-3 16:22
这个我实验了，好像没有这两个配置，还是会按默认的3600秒和1M来进行checkpoint，而且我刚发现好像hadoop ...

hadoop2.2中fs.checkpoint.period已经被遗弃，使用dfs.namenode.checkpoint.period
推荐参考
Hadoop2.2.0已经遗弃的属性名称及新的属性名称对比表

qcbb001 发表于 2017-1-3 17:03
hadoop2.2中fs.checkpoint.period已经被遗弃，使用dfs.namenode.checkpoint.period
推荐参考
Hadoop2.2 ...

非常感谢，这个正是我需要的，还有就是这里写的2.2  我版本用的是cdh4.4-hadoop2.0 应该也是已经更新用新的配置了吧

HawCHing 发表于 2017-1-3 17:18
非常感谢，这个正是我需要的，还有就是这里写的2.2  我版本用的是cdh4.4-hadoop2.0 应该也是已经更新用新 ...

不出意外的应该是hadoop2.x的都是这样的。如果是比较重要的，还是谨慎操作