Hadoop安全模式恢复 - 耗时太长!

时间:2011-02-11 07:28:08

标签: hadoop safe-mode

我有一个包含18个数据节点的Hadoop集群。 我在两小时前重新启动了名称节点,名称节点仍处于安全模式。

我一直在寻找为什么这可能需要太长时间,我找不到一个好的答案。 发布在这里: Hadoop safemode recovery - taking lot of time 是相关的,但我不确定是否需要/需要在更改此设置后重新启动名称节点,如该文章所述:

<property>
 <name>dfs.namenode.handler.count</name>
 <value>3</value>
 <final>true</final>
</property>

在任何情况下,这都是我在'hadoop-hadoop-namenode-hadoop-name-node.log'中得到的:

2011-02-11 01:39:55,226 INFO org.apache.hadoop.ipc.Server: IPC Server handler 0 on 8020, call delete(/tmp/hadoop-hadoop/mapred/system, true) from 10.1.206.27:54864: error: org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot delete /tmp/hadoop-hadoop/mapred/system. Name node is in safe mode.
The reported blocks 319128 needs additional 7183 blocks to reach the threshold 0.9990 of total blocks 326638. Safe mode will be turned off automatically.
org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot delete /tmp/hadoop-hadoop/mapred/system. Name node is in safe mode.
The reported blocks 319128 needs additional 7183 blocks to reach the threshold 0.9990 of total blocks 326638. Safe mode will be turned off automatically.
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.deleteInternal(FSNamesystem.java:1711)
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:1691)
    at org.apache.hadoop.hdfs.server.namenode.NameNode.delete(NameNode.java:565)
    at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:508)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:966)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:962)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:416)
    at org.apache.hadoop.ipc.Server$Handler.run(Server.java:960)

任何建议表示赞赏。 谢谢!

2 个答案:

答案 0 :(得分:44)

我有过一次,其中一些块从未报告过。我不得不强行让namenode离开safemode(hadoop dfsadmin -safemode leave),然后运行fsck删除丢失的文件。

答案 1 :(得分:0)

检查hdfs-site.xml中的dfs.namenode.handler.count属性。

hdfs-site.xml中的

dfs.namenode.handler.count指定Namenode用于处理的线程数。其默认值为10。此属性的值太小可能会导致指定的问题。

还要检查丢失或损坏的块 hdfs fsck / | egrep -v'^。+ $'| grep -v复制

hdfs fsck / path / to / corrupt / file -locations -blocks -files

如果找到损坏的块,请将其删除。 hdfs fs -rm / file-with-missing-corrupt块。