标签：
本文通过一个在实际工作中所遇到的线上问题来告诉广大数据从业者一条通俗有用的人生哲理：线上遇到这样的问题，千万要冷静，越是着急越容易出乱子！心急吃不了热豆腐。
上周二，朋友公司的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恢复正常。
测试能正常上传下载数据，确认各项指标都正常，集群恢复可用。整个修复过程耗时半个小时。
线上遇到这样的问题，千万要冷静，越是着急越容易出乱子！
（来源：平民大数据）
标签：
原文地址：http://www.cnblogs.com/javadba/p/4419817.html
