十万火急

      上周二，朋友公司的Hadoop集群服务不可用，从早上9点开始一直持续到12点。业务方催得比较急，希望尽快恢复，至少给个可以恢复的时间点。这种心情做过线上服务运维的同学应该都能理解。特别是在没有任何思路的情况下,就只能干着急！

症状了解

朋友联系我，咨询了下具体症状为namenode启动过程中，一直打印如下log：

    这个情况以前也没遇到过，询问了下当前使用的版本是2.4.0，看log 是info 级别，判断数据应该没什么问题。

查阅资料

    这种问题一般直接google hadoop jira

     打开第一个链接，搜索关键字： does not belong to any file

大致浏览发现与https://issues.apache.org/jira/browse/HDFS-7503 描述现象类似

      大体上讲如果在删除大量文件之后立即重启集群，会因大量打印游离块信息，namenode很长一段时间都会在安全模式之下，导致namenode长时间不可用。这个问题将在2.6.1和1.3.0的版本中被修复。

信息确认

      跟朋友确认了一下，确实在前一天有大批量删除文件的操作，删除的文件数高达700多W之多。大概能确定情况和这个jira 提到的一致。粗略估计了若每秒打印100条info log，那么700多W大概需要1天的时间才能打印完成。最直接的解决方法就是降低日志级别。

操作：动态设置调整日志级别

不重启降低namenode的log级别，打开http://{your_namenode_ip}:50070/logLevel

查看源码，找到打印这个log的类的全路径，输入

org.apache.hadoop.hdfs.server.blockmanagement.BlockManager查看log级别为INFO，

将其设置成“WARN”，查看namenode的最新log，没有变化，等待一会，依然持续打印，问题没有解决。

判断应该是log类别没有调对，继续查看打印这段log的源码：

具体打印log的是blockLog

      实际上对应的log类别应该是：BlockStateChange ! 其实从打印出来日志就可以看出来的。

     在Log中输入”BlockStateChange”，Level输入”WARN“，然后点击”Set log level”按钮。

     查看namenode log ，log马上停止，不过还打印其他信息，确认生效，等待2-3分钟，log恢复正常。

     测试能正常上传下载数据，确认各项指标都正常，集群恢复可用。整个修复过程耗时半个小时。

线上遇到这样的问题，千万要冷静，越是着急越容易出乱子！