Работает 0 datanode (s), и в этой операции исключаются node (s)

Ответ 1

Две вещи работали для меня,

ШАГ 1: остановить hadoop и очистить файлы temp от hduser

sudo rm -R /tmp/*

также вам может понадобиться удалить и воссоздать /app/hadoop/tmp (в основном, когда я изменяю версию hadoop от 2.2.0 до 2.7.0)

sudo rm -r /app/hadoop/tmp
sudo mkdir -p /app/hadoop/tmp
sudo chown hduser:hadoop /app/hadoop/tmp
sudo chmod 750 /app/hadoop/tmp

ШАГ 2: форматирование namenode

hdfs namenode -format

Теперь я вижу DataNode

[email protected]:~$ jps
19135 NameNode
20497 Jps
19477 DataNode
20447 NodeManager
19902 SecondaryNameNode
20106 ResourceManager

Ответ 2

У меня была такая же проблема после неправильного завершения работы node. Также проверяется в пользовательском интерфейсе, в котором нет данных.

Теперь он работает после удаления файлов из папки datanode и перезапуска служб.

stop-all.sh

rm -rf/usr/local/hadoop_store/hdfs/datanode/*

start-all.sh

Ответ 3

@Learner,
У меня была эта проблема с datanodes, которая не показана в пользовательском интерфейсе Namenode. Решила его этими шагами в Hadoop 2.4.1.

сделать это для всех узлов (master и slaves)

1. удалить все временные файлы (по умолчанию в /tmp ) - sudo rm -R /tmp/*.
2. Теперь попробуйте подключиться ко всем узлам через ssh, используя ssh [email protected], и добавьте ключи в свой мастер с помощью ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected], чтобы предоставить неограниченный доступ подчиненных устройств к главному устройству (при этом не может быть проблемой для отказа в подключении).
3. Отформатируйте namenode с помощью hadoop namenode -format и попробуйте перезапустить демоны.

Ответ 4

В моей ситуации работал firewalld. Это было по умолчанию. И это не позволяет общаться между узлами. Мой кластер hadoop был тестовым кластером. Из-за этого я остановил службу. Если ваши серверы находятся в процессе производства, вы должны разрешить использование портов suoop на firewalld вместо

service firewalld stop
chkconfig firewalld off

Ответ 5

У меня была такая же ошибка. У меня не было разрешения на файловую систему hdfs. Поэтому я даю разрешение моему пользователю:

chmod 777 /usr/local/hadoop_store/hdfs/namenode
chmod 777 /usr/local/hadoop_store/hdfs/datanode

Ответ 6

В моей ситуации мне не хватало необходимых свойств внутри hdfs-site.xml (Hadoop 3.0.0), установленного с помощью HomeBrew на MacOS. (file:/// не является опечаткой.)

<property>
    <name>dfs.namenode.name.dir</name>
    <value>file:///usr/local/Cellar/hadoop/hdfs/namenode</value>
</property>

<property>
    <name>dfs.datanode.data.dir</name>
    <value>file:///usr/local/Cellar/hadoop/hdfs/datanode</value>
</property>

Ответ 7

Вероятно, это связано с тем, что идентификатор кластера данных datanodes и namenodes или диспетчер node не совпадают. Идентификатор кластера можно увидеть в файле VERSION, найденном как в namenode, так и в datanodes.

Это происходит, когда вы форматируете свой namenode и затем перезапускаете кластер, но datanodes все еще пытаются подключиться с использованием предыдущего идентификатора clusterID. для успешного подключения вам нужен правильный IP-адрес, а также соответствующий идентификатор кластера на узлах.

Итак, попробуйте переформатировать namenode и datanodes или просто настройте datanodes и namenode на вновь созданных папках.

Это должно решить вашу проблему.

Удаление файлов из текущей папки datanodes также удалит старый файл VERSION и запросит новый файл VERSION при повторном подключении к namenode.

Пример: каталог datanode в конфигурации есть /hadoop 2/datanode

$ rm -rvf /hadoop2/datanode/*

И затем перезапустите службы Если вы переформатируете свой namenode, сделайте это до этого шага. Каждый раз, когда вы переформатируете свой namenode, он получает новый идентификатор, и этот идентификатор генерируется случайным образом и не будет соответствовать старому идентификатору в ваших datanodes.

Итак, каждый раз следуйте этой последовательности

если вы форматируете namenode   затем Удалить содержимое каталога данных datanode ИЛИ настроить datanode на вновь созданный каталог   Затем запустите свой namenode и datanodes

Ответ 8

Значение свойства {fs.default.name} в файле core-site.xml, как на главном, так и на ведомом компьютере, должно указывать на мастер-машину. Итак, это будет примерно так:

<property>
     <name>fs.default.name</name>
     <value>hdfs://master:9000</value>
</property>

где master - это имя хоста в файле /etc/hosts, указывающее на мастер node.

Ответ 9

Вы пробовали очистить папку /tmp.

До очистки датанода не подходила

86528 SecondaryNameNode
87719 Jps
86198 NameNode
78968 RunJar
79515 RunJar
63964 RunNiFi
63981 NiFi

После очистки

sudo rm -rf /tmp/*

У меня сработало

89200 Jps
88859 DataNode

Ответ 10

Решение @mustafacanturk, отключение брандмауэра работало для меня. Я думал, что датододы запускаются, потому что они появляются при запуске jps, но при попытке загрузить файлы я получаю сообщение "0 узлов работает". На самом деле ни один из веб-интерфейсов (http://nn1: 50070) не работал из-за брандмауэра. Я отключил брандмауэр при установке hadoop, но по какой-то причине это произошло. Тем не менее, иногда чистка или воссоздание временных папок (hadoop.tmp.dir) или даже папок dfs.data.dir и dfs.namenode.name.dir и переформатирование сервера имен были решением.

Ответ 11

1) Сначала остановите все службы, используя команду stop-all.sh

2) Удалите все файлы внутри datanode rm -rf/usr/local/hadoop_store/hdfs/datanode/*

3) Затем запустите все службы, используя команду start-all.sh

Вы можете проверить, работают ли все ваши службы с помощью команды jps

Надеюсь, что это сработает!!!