标签：
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的值的路径。
删除之后，重新启动集群即可。
标签：
原文地址：http://www.cnblogs.com/ljy2013/p/4705537.html
