发帖
雷达卡
十万火急
上周二，朋友公司的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恢复正常。
测试能正常上传下载数据，确认各项指标都正常，集群恢复可用。整个修复过程耗时半个小时。
线上遇到这样的问题，千万要冷静，越是着急越容易出乱子！
的时候，雨也是晴；心雨
的时候，晴也是雨！
京公网安备 11010802022788号
