Подтвердить что ты не робот

Hadoop safemode recovery - слишком долго!

У меня есть Hadoop-кластер с 18 узлами данных. Я перезапустил имя node более двух часов назад, а имя node все еще находится в безопасном режиме.

Я искал, почему это может занять слишком много времени, и я не могу найти хороший ответ. Сообщение здесь: Восстановление безопасности в режиме Hadoop - много времени. имеет значение, но я не уверен, что мне нужно/нужно перезапустить имя node после внесения изменений в этот параметр, как упоминается в этой статье:

<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)

Любые советы приветствуются. Спасибо!

4b9b3361

ОТВЕТЫ

Ответ 1

Я использовал его один раз, когда некоторые блоки никогда не сообщались. Мне пришлось принудительно разрешить namenode оставить safemode (hadoop dfsadmin -safemode leave), а затем запустить fsck для удаления отсутствующих файлов.

Ответ 2

Проверьте свойства dfs.namenode.handler.count в hdfs-site.xml.

dfs.namenode.handler.count в hdfs-site.xml указывает количество потоков, используемых Namenode для его обработки. значение по умолчанию равно 10. Слишком низкое значение этого свойства может вызвать указанную проблему.

Также проверьте отсутствующие или поврежденные блоки hdfs fsck/| egrep -v '^. + $' | реплика grep -v

hdfs fsck/path/to/поврежденный/файл -locations -блоки -files

если поврежденные блоки найдены, удалите их. hdfs fs -rm/файл с отсутствующими поврежденными блоками.