Hadoop 安全模式恢复 - 耗时太长！答案

【问题标题】：Hadoop safemode recovery - taking too long!Hadoop 安全模式恢复 - 耗时太长！
【发布时间】：2011-02-11 07:28:07
【问题描述】：

我有一个包含 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)

感谢任何建议。谢谢！

【问题讨论】：

你的复制因子是多少？
复制因子为 3。它仍然处于安全模式！
K，是的，你肯定应该选择更高的处理程序数量，应该在 10 左右。

标签： hadoop safe-mode

【解决方案1】：

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

【讨论】：

在等待几个小时后，我最终不得不运行“-safemode leave”。仍然有丢失的块，所以我还需要运行 fsk 来删除丢失的文件。
你知道 hdfs 不能自己恢复丢失的副本的原因吗？
然后使用hadoop fsck -delete清理数据。
@xinit，@shane，@senile_genius，@Denis，我用hadoop dfsadmin -safemode leave，那么datanode上文件的所有block信息都找不到了。即使在网络界面 nn1 上，文件名仍然存在，由于无法找到块信息，因此无法下载文件。如何解决这个问题？

【解决方案2】：

检查 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 blocks.

【讨论】：