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

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

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

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

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

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

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

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

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

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

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

继昨天解决Kafka的位移问题后，今天又发现一个hbase的region server无法重新启动的问题。这个server本身是有问题的，目前问题还未查。但是再重启的时候，会报三组错。其中一个明确为PG的错误，大意如下

首先想到的就是检查本地磁盘，发现其实并没有满，这就很奇怪了。之后想到CDH会使用pg，那就把这部分先了解下。

查询了一下，发现确实是的，会有一个地方存储着pg相关登录信息。按网文说是 /etc/cloudera-scm-server ，但我发现几个机器都只有 /etc/cloudera-scm-agent 。所以必须找到server的机器，而其他集群里的都是agent的机器。

找到这个机器后，发现确实是空间满了。

那么依次用 du -h --max-depth 1 命令查看目录，最终发现CDH的kafka manager的nohup文件是罪魁祸首。

用 >nohup.out 把文件清空，再用CDH重启节点就没有问题了！

搭建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

---