Hadoop急诊室的半小时
十万火急
上周二，朋友公司的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恢复正常。
测试能正常上传下载数据，确认各项指标都正常，集群恢复可用。整个修复过程耗时半个小时。
线上遇到这样的问题，千万要冷静，越是着急越容易出乱子!
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
