Восстановление в безопасном режиме Hadoop - занимает слишком много времени!

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

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

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

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


hadoop safe-mode
person senile_genius    schedule 11.02.2011    source источник
comment
Какой у вас фактор репликации?   -  person Thomas Jungblut    schedule 11.02.2011
comment
Коэффициент репликации равен 3. И все еще в безопасном режиме!   -  person senile_genius    schedule 11.02.2011
comment
K, да, вам определенно следует выбрать большее количество хендлеров, должно быть около 10.   -  person Thomas Jungblut    schedule 11.02.2011

Ответы (2)


arrow_upward
45
arrow_downward

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

person xinit    schedule 16.02.2011
comment
В итоге мне пришлось запустить «-safemode leave» после нескольких часов ожидания. По-прежнему есть недостающие блоки, поэтому мне также нужно будет запустить fsk, чтобы удалить отсутствующие файлы. - person senile_genius; 17.02.2011
comment
Знаете ли вы, почему hdfs не восстанавливает недостающие реплики самостоятельно? - person Denis; 14.04.2015
comment
Затем используйте hadoop fsck -delete для очистки данных. - person shane; 11.05.2017
comment
@xinit, @shane, @senile_genius, @Denis, я использую hadoop dfsadmin -safemode leave, тогда вся информация о блоках для файлов на датаноде не может быть найдена. Даже в веб-интерфейсе nn1 имена файлов все еще присутствуют, файлы не могут быть загружены, так как информация о блоке больше не может быть найдена. Как решить эту проблему? - person Yu Xiang; 08.04.2021

arrow_upward
0
arrow_downward

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

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

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

hdfs fsck / путь / к / коррумпированному / файлу -locations -blocks -files

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

person Pravat Sutar    schedule 15.08.2019