CDH nameNode 文件检查点状态异常解决

Posted 2023-04-08

参考技术A 最近，看了几部女主戏，觉得里面的男绿叶眼神里总是饱含着忧伤，总是不快乐。其实女主戏里的男主，更加真实，因为他们背负着女主给他们的压力和不快乐。比如，最近HDFS集群不时会有以下异常：

每次出现该异常，重启HDFS集群，就可以恢复正常。但生产环境肯定不能三天两头重启集群。于是尝试HA机制下滚动重启。

系统的NameNode已经开启了HA模式，即主备模式。

最开始，由于异常发生在NameNode主节点，认为是主节点checkpoint发生异常，故重启主节点，预期会产生主备切换，但重启之后，并未发生主备切换，主节点依然不良。

并且在活动节点重启时，发生了以下告警：

意味着并未发生主备切换，而是集群直接不良，也就是说，其实出问题的是备用节点。

那就直接重启备用节点好了，依然出现开始的问题。

也就是说，备用节点上的checkpoint出现了问题，可能和主节点不同步。

尝试停止备用节点，删除备用节点上的/dfs/nn1目录，并把主节点的/dfs/nn1目录scp到备用节点上。再启动，问题解决。

结论：备用节点因为未知原因失去了和JournalNodes的通信，导致落后，但备用节点在重启之后并不会追赶主节点的事务变化。可能和JournalNodes的设计是轻量级，并未保存失去通信和重启这一段时间所有的事务。因此必须通过手动同步实现主备节点的edit log一致。以上仅是个人推测，还望运维店长斧正。

CDH6.3配置HDFS高可用，多NameNode

参考技术A 搭建HDFS的NameNode集群, 在单个NameNode宕机或繁忙时, 可以做故障转移和压力平摊; 配置的过程比较复杂, 网上的可查资料也很少

开启了高可用, 不需要SecondaryNameNode, 该角色并不具备故障转移的功能, 可以理解为一个备份点, 解读Secondary NameNode的功能 ;

在只有一个NameNode的情况下, 必须配置SecondaryNameNode; 但多个NameNode的时候, 如果没删除会报错校验不通过, 这里先忽略不理

建议NameNode进行一次格式化, DataNode的数据目录进行清空, 生产环境慎重操作. 重启的时候DataNode放在最后执行, 确保所有的节点都是正常的, 通过Hadoop的UI可以查看准确的状态(9870端口); 如果在日志种出现如下报错, Block pool ID needed, but service not yet registered with NN
可尝试在每台DataNode将错误的文件删掉(/dfs/dn/current), 日志中有详细的打印, 删除之后节点状态恢复正常

执行hdfs的增删改查命令做测试, 如cat,ls,put,mkdir等, 通过即为正常

NameNode和Failover Controller所在的机器要一一对应, NameNode还要执行zkfc命令进行初始化, 在运行Controller要开启故障转移, 并要确保初始化Zk的命令

去NameNode的机器执行离开安全的操作

/var/run的权限过大, 把/var/run/hdfs-sockets目录删掉或重新授权

在不开启高可用的时候, 必须配置SecondaryNameNode

官方NameNode高可用配置说明
解读Secondary NameNode的功能
Cannot find any valid remote NN to service request