Hadoop:... будет реплицироваться на 0 узлов вместо minReplication (= 1). Работает 1 datanode (s), и в этой операции исключаются node (s)

Ответ 1

Эта ошибка вызвана системой репликации блоков HDFS, так как она не смогла сделать какие-либо копии определенного блока в фокусированном файле. Общие причины этого:

1. Только экземпляр NameNode работает и не находится в безопасном режиме
2. Нет экземпляров DataNode, запущенных или работающих, или некоторые из них мертвы. (Проверьте серверы)
3. Оба экземпляра Namenode и Datanode работают, но они не могут взаимодействовать друг с другом, что означает, что существует проблема соединения между экземплярами DataNode и NameNode.
4. Запущенные экземпляры DataNode не могут общаться с сервером из-за некоторых проблем с сетью, связанных с Hadoop (проверьте журналы, которые содержат информацию о датодах)
5. В настроенных каталогах данных для экземпляров DataNode или DataNode не осталось свободного места на жестком диске. (проверьте dfs.data.dir//удалите старые файлы, если они есть)
6. Заданные зарезервированные пространства для экземпляров DataNode в dfs.datanode.du.reserved - это больше, чем свободное пространство, которое заставляет экземпляры DataNode понять, что свободного места недостаточно.
7. Для экземпляров DataNode недостаточно потоков (проверьте журналы датоделей и значение dfs.datanode.handler.count)
8. Убедитесь, что dfs.data.transfer.protection не равно "аутентификации", а dfs.encrypt.data.transfer равно true.

Также, пожалуйста:

• Проверьте состояние сервисов NameNode и DataNode и проверьте соответствующие журналы
• Убедитесь, что для core-site.xml указано правильное значение fs.defaultFS, а для hdfs-site.xml указано правильное значение.
• Убедитесь, что hdfs-site.xml имеет dfs.namenode.http-address.. для всех экземпляров NameNode, указанных в случае конфигурации PHD HA.
• Проверьте правильность разрешений для каталогов

Ссылка: https://wiki.apache.org/hadoop/CouldOnlyBeReplicatedTo

Ссылка: https://support.pivotal.io/hc/en-us/articles/201846688-HDFS-reports-Configured-Capacity-0-0-B-for-datanode

Также, пожалуйста, проверьте: при записи в HDFS из Java, получение "может быть реплицировано только на 0 узлов вместо minReplication"

Ответ 2

Недавно у меня была аналогичная проблема. Поскольку у моих datanodes (только) были SSD для хранения, я положил [SSD]file:///path/to/data/dir для конфигурации dfs.datanode.data.dir. Из-за журналов, содержащих unavailableStorages=[DISK], я удалил тег [SSD], который решил проблему.

По-видимому, Hadoop использует [DISK] как тип хранилища по умолчанию и не использует "резервный" (или, скорее, "fallup" ) для использования SSD, если не существует тега хранения [DISK]. Однако я не мог найти никакой информации о таком поведении.

Ответ 3

Проверьте, jps ли команда jps на компьютерах, на которых выполняются узлы данных, действующие. Если они работают, то это означает, что они не могли соединиться с namenode, и, следовательно, namenode думает, что в системе hadoop отсутствуют датододы.

В таком случае после запуска start-dfs.sh запустите netstat -ntlp в главном узле. 9000 - это номер порта, который в большинстве уроков core-site.xml указывать в core-site.xml. Так что если вы видите такую строку в выводе netstat

tcp        0      0 120.0.1.1:9000        0.0.0.0:*               LISTEN       4209/java

тогда у вас есть проблема с псевдонимом хоста. У меня была такая же проблема, поэтому я сообщу, как она была решена.

Это содержимое моего core-site.xml

<configuration>
   <property>
       <name>fs.default.name</name>
       <value>hdfs://vm-sm:9000</value>
   </property>
</configuration>

Таким образом, псевдоним vm-sm в главном компьютере соответствует 127.0.1.1. Это из-за настройки моего файла /etc/hosts.

127.0.0.1       localhost
127.0.1.1       vm-sm
192.168.1.1     vm-sm
192.168.1.2     vm-sw1
192.168.1.3     vm-sw2

Похоже, что core-site.xml главной системы, по-видимому, отображался на 120.0.1.1:9000 то время как тот из рабочих узлов пытается подключиться через 192.168.1.1:9000.

Поэтому мне пришлось изменить псевдоним главного узла для системы hadoop (только что удалил дефис) в /etc/hosts

127.0.0.1       localhost
127.0.1.1       vm-sm
192.168.1.1     vmsm
192.168.1.2     vm-sw1
192.168.1.3     vm-sw2

и отразил изменение в core-site.xml, mapred-site.xml и slave (везде, где встречался старый псевдоним мастера).

После удаления старых файлов hdfs из папки hadoop, а также из папки tmp и перезапуска всех узлов проблема была решена.

Теперь netstat -ntlp после запуска DFS возвращает

tcp        0      0 192.168.1.1:9000        0.0.0.0:*               LISTEN ...
...

Ответ 4

У меня была такая же ошибка, перезапуск сервисов hdfs решил эту проблему. т.е. перезапущенные сервисы NameNode и DataNode.

Ответ 5

В моем случае это была политика хранения выходного пути, установленная на COLD.

Как проверить настройки вашей папки:

hdfs storagepolicies -getStoragePolicy -path my_path

В моем случае это вернулось

The storage policy of my_path
BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}   

Я сбросил данные еще где (в ГОРЯЧЕЕ хранилище) и проблема ушла.

Ответ 6

Вы можете выйти из безопасного режима HDFS:

hdfs dfsadmin -safemode forceExit