1、问题的描述
由于某种原因,需要在原来已经部署了Cloudera CDH集群上重新部署,重新部署之后,启动集群,由于Cloudera Manager 会默认设置dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns分别是1个小时和1000000。只要达到这两个条件之一,secondarynamenode会执行checkpoint操作,此时会出现如下的问题:
ERROR:The health test result for NAME_NODE_HA_CHECKPOINT_AGE has become bad: The filesystem checkpoint is 4 hour(s) old. This is 401.25% of the configured checkpoint period of 1 hour(s). Critical threshold: 400.00%. 2,793 transactions have occurred since the last filesystem checkpoint. This is 0.28% of the configured checkpoint transaction target of 1,000,000.
经过初步分析,是由于secondarynamenode没有执行checkpoint的原因所导致,于是就查看了一下secondarynamenode的日志,发现真正的错误是:
ERROR: Exception in doCheckpoint java.io.IOException: Inconsistent checkpoint field
此时,说明查看个角色运行的日志很重要的,能够很精确的定位错误所在。
那么这两个问题的联系是什么呢?主要是secondarynamenode没有执行检查点的操作,导致会产生上面的错误,上面的错误说明的是你一直没有执行检查点的操作。下面的错误说明的是执行检查点操作失败,不执行。
2、问题的解决前的知识储备
在解决问题之前首先需要介绍一下检查点的作用及重要性。
(1)检查点
何为检查点:检查点是给secondarynamenode设置的,通过设置hdfs-site.xml中参数dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns 来触发,只要达到这两个条件之一就可以出发secondarynamenode执行检查点的操作。
(2)检查点的的内容:
secondarynamenode执行检查点的内容是首先从namenode中读取Fsimage,并执行namenode中editslog文件中的操作,并最终生成一个新的FSimage文件,并将这个文件上传给Namenode。注意 :在这个过程中,如果editlog没有任何的记录的话,达到了检查点的条件后,也由于没有发生任何改变,因此不执行检查点操作。
(3)检查点的作用:
secondarynamenode执行这个检查点的操作,可以减少namenode的启动时间。
3、问题的解决方法
通过真正的错误的描述,发现主要是版本不匹配,说明在重新安装CDH的时候,保留了以前版本的CDH的数据,导致不一致的版本问题,所以导致secondarynamenode不执行检查点的操作。那么解决办法就是删除之前的数据,所以通过删除secondarynamenode执行检查点是的目录,即hdfs-site.xml中参数fs.checkpoint.dir, dfs.namenode.checkpoint.dir的值的路径。
删除之后,重新启动集群即可。