Hadoop急诊室的半小时

机器学习 4026 Views

数盟致力于成为最卓越的数据科学社区,聚焦于大数据、分析挖掘、数据可视化领域,业务范围:线下活动、在线课程、猎头服务、项目对接】

十万火急

上周二,朋友公司的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恢复正常。

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

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

—————————————————

数盟网站:www.dataunion.org

数盟微博:@数盟社区

数盟微信:DataScientistUnion

数盟【大数据群】272089418

数盟【数据可视化群】 179287077

数盟【数据分析群】 110875722

—————————————————

点击阅读原文,更多精彩技术、资讯内容~

如未说明则本站原创,转载请注明出处:NULL » Hadoop急诊室的半小时