Ошибка HDFS: может быть реплицирована только на 0 узлов, а не на 1

Question

Я создал кластер hadoop для Ubuntu с одним узлом в EC2.

Тестирование простой загрузки файла в hdfs работает с машины EC2, но не работает с машины за пределами EC2.

Я могу просматривать файловую систему через веб-интерфейс с удаленногомашина, и это показывает один датодан, который сообщается как в обслуживании.Открыли все порты TCP в безопасности от 0 до 60000 (!), Так что я не думаю, что это так.

Я получаю сообщение об ошибке

java.io.IOException: File /user/ubuntu/pies could only be replicated to 0 nodes, instead of 1
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:1448)
at org.apache.hadoop.hdfs.server.namenode.NameNode.addBlock(NameNode.java:690)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:342)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1350)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1346)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:742)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1344)

at org.apache.hadoop.ipc.Client.call(Client.java:905)
at org.apache.hadoop.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:198)
at $Proxy0.addBlock(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
at $Proxy0.addBlock(Unknown Source)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.locateFollowingBlock(DFSOutputStream.java:928)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:811)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:427)

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

Есть идеи?

Приветствия

Answer 1

Не форматируйте имя узла немедленно. Попробуйте stop-all.sh и запустите его, используя start-all.sh. Если проблема не устранена, перейдите к форматированию имени узла.

Answer 2

У меня тоже была такая же проблема / ошибка. Проблема возникла в первую очередь, когда я отформатировал, используя hadoop namenode -format

Таким образом, после перезапуска hadoop с использованием start-all.sh узел данных не запустился или не инициализировался. Вы можете проверить это с помощью jps, там должно быть пять записей. Если датодода отсутствует, вы можете сделать это:

Процесс Datanode не работает в Hadoop

Надеюсь, это поможет.

Answer 3

Речь идет о SELINUX.В моих случаях CentOS 6.5

Весь узел (имя, секунда, данные ....)

Служба iptables stop

Answer 4

Я понимаю, что немного опоздал на вечеринку, но я хотел опубликовать это для будущих посетителей этой страницы.У меня была очень похожая проблема, когда я копировал файлы с локального в hdfs, и переформатирование namenode не решило проблему для меня.Оказалось, что в моих журналах namenode было следующее сообщение об ошибке:

2012-07-11 03:55:43,479 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(127.0.0.1:50010, storageID=DS-920118459-192.168.3.229-50010-1341506209533, infoPort=50075, ipcPort=50020):DataXceiver java.io.IOException: Too many open files
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:883)
        at org.apache.hadoop.hdfs.server.datanode.FSDataset$FSVolume.createTmpFile(FSDataset.java:491)
        at org.apache.hadoop.hdfs.server.datanode.FSDataset$FSVolume.createTmpFile(FSDataset.java:462)
        at org.apache.hadoop.hdfs.server.datanode.FSDataset.createTmpFile(FSDataset.java:1628)
        at org.apache.hadoop.hdfs.server.datanode.FSDataset.writeToBlock(FSDataset.java:1514)
        at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.<init>(BlockReceiver.java:113)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:381)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:171)

По-видимому, это относительно распространенная проблема на кластерах hadoop, и Cloudera предлагает увеличить пределы nofile и epoll (еслина ядре 2.6.27), чтобы обойти это.Хитрость в том, что установка пределов nofile и epoll сильно зависит от системы.Моему серверу Ubuntu 10.04 требовалась немного другая конфигурация , чтобы это работало должным образом, поэтому вам, возможно, придется изменить свой подход соответствующим образом.

Answer 5

Переформатирование узла не является решением.Вам нужно будет отредактировать start-all.sh.Запустите dfs, дождитесь его полного запуска и затем запустите mapred.Вы можете сделать это, используя сон.Ожидание 1 секунды сработало у меня.Смотрите полное решение здесь http://sonalgoyal.blogspot.com/2009/06/hadoop-on-ubuntu.html.

Answer 6

Вы пробовали рекомендацию из вики http://wiki.apache.org/hadoop/HowToSetupYourDevelopmentEnvironment?

Я получал эту ошибку при вводе данных в DFS. Решение странное и, вероятно, несовместимое: я стер все временные данные вместе с namenode, переформатировал namenode, запустил все и посетил страницу здоровья моего dfs кластера (http://your_host:50070/dfshealth.jsp). Последний шаг, посещение страницы здоровья, это Единственный способ обойти эту ошибку. После того, как я зашел на страницу, вставка и получение файлов в и из dfs работает отлично!