CDH6.3拆除namenode的高可用报错

报错内容:

文件系统检查点已有 2 天,16 小时,54 分钟。占配置检查点期限 1 小时的 6,490.14%。 临界阈值:400.00%。 自上个文件系统检查点以来已发生 63,898 个事务。这是 1,000,000 的已配置检查点事务目标的 6.39%。

马上查看log文件发现secondarynamenode报错检测不到edits文件

ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Exception in doCheckpoint

java.io.IOException: Found no edit logs to download on NN since txid 10098943

啥情况啊,百度发现一篇类似问题的文章,讲解的非常详细关于监测点内容

https://blog.csdn.net/liujiyu1989/article/details/47829083

但是博主是secondarynamenode没有执行执行检查点的操作,而我这是没有找到edits文件,所有还得继续排查

因为集群部署不是我搭建的,我刚刚临时接手处理

发现集群上面搭建过高可用namenode,上面有journalNode在运行但是没有stand by NameNode

奇怪啊!问了一下前同事说拆除了然后加了一个secondarynamenode,原来如此

那么问题就很清楚了:(发现如果journalNode存在edits文件不会写到namenode)

1、journalNode存在但是没有stand by NameNode 所有导致edits和fsimages不能合并

2、增加了secondarynamenode但是edits文件不在namenode里面,所有secondarynamenode检测不到不能合并edits和fsimages

解决:

先将journalNode停用,马上namenode就会因为不能写入edits文件而报错停止了,然后将journalNode里面的edits移到namenode里面去(请备份在操作),单独重启namenode,发现namenode报错起不来,

java.io.IOException: Gap in transactions. Expected to be able to read up until at least txid 10177335 but unable to find any edit logs containing txid 10175587

还是edits的路径没有切换过去,去CM界面查看一下配置edits的路径,发现默认就是 namenode

那就给他配置上/hdfs/opt/dfs/nn(和默认路径完全相同),配置好了整个集群重启,发现OK了

很奇怪为什么一定要配置,后面我将配置的路径去掉了再重启集群也是可以的,所有怀疑是我将edits文件替换后只是启动了namenode不行,应该重启集群才可以,最后总算弄好了,虽然是测试集群但是里的数据还是很多的,还是要小心处理

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页