amazon-ec2 - paga - aws calculadora de precios

Error HDFS: solo se pudo replicar en 0 nodos, en lugar de 1

Question

Creé un clúster de hadoop de un nodo ubuntu en EC2.

Probar una simple carga de archivos a hdfs funciona desde la máquina EC2, pero no funciona desde una máquina fuera de EC2.

Puedo navegar por el sistema de archivos a través de la interfaz web desde la máquina remota, y muestra un nodo de datos que se informa como en servicio. Han abierto todos los puertos tcp en la seguridad de 0 a 60000 (!) Así que no creo que sea eso.

Me sale el error

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 log solo da el mismo error. Otros no parecen tener nada interesante

¿Algunas ideas?

Aclamaciones

Answer 1

¿Has probado la recomendación de la wiki http://wiki.apache.org/hadoop/HowToSetupYourDevelopmentEnvironment ?

Estaba obteniendo este error al poner datos en el dfs. La solución es extraña y probablemente inconsistente: borré todos los datos temporales junto con el namenode, formateé de nuevo el namenode, comencé todo y visité la página de salud de dfs de mi "clúster" (http: // your_host: 50070 / dfshealth.jsp). El último paso, visitar la página de estado, es la única forma de evitar el error. Una vez que he visitado la página, ¡poner y recibir archivos dentro y fuera del dfs funciona muy bien!

Answer 2

Este es su problema: el cliente no puede comunicarse con el nodo de datos. Porque la IP que el cliente recibió para el Datanode es una IP interna y no la IP pública. Mira esto

http://www.hadoopinrealworld.com/could-only-be-replicated-to-0-nodes/

Mire el código fuente de DFSClient $ DFSOutputStrem (Hadoop 1.2.1)

//
// Connect to first DataNode in the list.
//
success = createBlockOutputStream(nodes, clientName, false);

if (!success) {
  LOG.info("Abandoning " + block);
  namenode.abandonBlock(block, src, clientName);

  if (errorIndex < nodes.length) {
    LOG.info("Excluding datanode " + nodes[errorIndex]);
    excludedNodes.add(nodes[errorIndex]);
  }

  // Connection failed. Let''s wait a little bit and retry
  retry = true;
}

La clave para entender aquí es que Namenode solo proporciona la lista de nodos de datos para almacenar los bloques. Namenode no escribe los datos en los nodos de datos. El trabajo del cliente es escribir los datos en los nodos de datos utilizando DFSOutputStream. Antes de que cualquier escritura pueda comenzar, el código anterior se asegura de que el Cliente pueda comunicarse con los Nodos de Datos y si la comunicación falla en el Nodo de Datos, el Nodo de Datos se agrega a los Nodos excluidos.

Answer 3

Me doy cuenta de que llegué un poco tarde a la fiesta, pero quería publicar esto para los futuros visitantes de esta página. Estaba teniendo un problema muy similar cuando estaba copiando archivos de local a hdfs y reformatear el namenode no me solucionó el problema. Resultó que mis registros namenode tenían el siguiente mensaje de error:

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)

Aparentemente, este es un problema relativamente común en los clústeres de hadoop y Cloudera sugiere aumentar los límites de nofile y epoll (si en el kernel 2.6.27) para evitarlo. Lo complicado es que establecer límites nofile y epoll depende en gran medida del sistema. Mi servidor Ubuntu 10.04 requirió una configuración ligeramente diferente para que esto funcione correctamente, por lo que es posible que deba modificar su enfoque en consecuencia.

Answer 4

Me tomó una semana descubrir el problema en mi situación.

Cuando el cliente (su programa) le pregunta a nameNode por la operación de datos, el nameNode toma un dataNode y lo conduce al cliente, dando la dirección IP del nodo de datos al cliente.

Pero, cuando el host de dataNode está configurado para tener múltiples IP, y el nombreNodo le proporciona el que su cliente NO PUEDE ACCEDER, el cliente agregará el nodo de datos para excluir la lista y le pedirá al nombreNodo una nueva, y finalmente todos los datosNode están excluidos, obtienes este error.

¡Así que comprueba la configuración de IP del nodo antes de probar todo!

Answer 5

Mira lo siguiente:

Al ver esta excepción (solo se pudo replicar en 0 nodos, en lugar de 1), el nodo de datos no está disponible para el Nodo de nombre.

Estos son los casos siguientes. El nodo de datos puede no estar disponible para el nodo Nombre

1. Disco de nodo de datos está lleno

2. El nodo de datos está ocupado con informe de bloque y escaneo de bloques

3. Si el tamaño del bloque es el valor negativo (dfs.block.size en hdfs-site.xml)

4. mientras se escribe en curso, el nodo de datos primario baja (Cualquier n / w fluctaciones b / w Nodo de nombre y Máquinas de nodo de datos)

5. cuando Ever agreguemos cualquier fragmento parcial y sincronización de llamadas para el siguiente fragmento parcial, el cliente debe almacenar los datos previos en el búfer.

Por ejemplo, después de agregar "a" llamé a sincronización y cuando intento agregar el buffer debería tener "ab"

Y del lado del servidor cuando el fragmento no es múltiplo de 512, entonces intentará hacer la comparación de Crc para los datos presentes en el archivo de bloque, así como el presente de crc en el metarchivo. Pero al construir crc para los datos presentes en el bloque, siempre se compara hasta el Offeset inicial o para un análisis más detallado. Por favor, los registros del nodo de datos.

Referencia: http://www.mail-archive.com/[email protected]/msg01374.html

Answer 6

No formatee el nodo de nombre inmediatamente. Pruebe stop-all.sh y comience usando start-all.sh. Si el problema persiste, vaya a formatear el nodo de nombre.

Answer 7

Reformatear el nodo no es la solución. Deberá editar el start-all.sh. Inicie el dfs, espere a que comience por completo y luego comience a mapear. Puedes hacer esto usando un sueño. Esperando 1 segundo funcionó para mí. Vea la solución completa aquí http://sonalgoyal.blogspot.com/2009/06/hadoop-on-ubuntu.html .

Answer 8

Se trata de SELINUX. En Mis casos, CentOS 6.5

Todos los nodos (nombre, segundo, datos ...)

servicio de parada de iptables

Answer 9

Si se están ejecutando todos los nodos de datos, una cosa más para verificar si el HDFS tiene suficiente espacio para sus datos. Puedo cargar un archivo pequeño pero no pude subir un archivo grande (30GB) a HDFS. ''bin / hdfs dfsadmin -report'' muestra que cada nodo de datos solo tiene unos pocos GB disponibles.

Answer 10

Siga los pasos a continuación:
1. Detener dfs e yarn .
2. Elimine los directorios de nodo de datos y namenode como se especifica en core-site.xml .
3. Comience dfs e yarn siguiente manera:

start-dfs.sh
start-yarn.sh
mr-jobhistory-daemon.sh start historyserver

Answer 11

También he tenido el mismo problema / error. El problema ocurrió en primer lugar cuando formateé con hadoop namenode-formate

Entonces, después de reiniciar el uso de hadoop, start-all.sh, el nodo de datos no se inició ni se inicializó. Puede verificar esto usando jps, debe haber cinco entradas. Si falta el nodo de datos, puede hacer esto:

Proceso de nodo de datos que no se ejecuta en Hadoop

Espero que esto ayude.

Answer 12

Trataré de describir mi configuración y solución: Mi configuración: RHEL 7, hadoop-2.7.3

Traté de configurar la Operación independiente primero y luego la Operación Pseudo Distribuida, donde la última falló con el mismo problema.

Aunque, cuando comienzo hadoop con:

sbin/start-dfs.sh

Obtuve lo siguiente:

Starting namenodes on [localhost]
localhost: starting namenode, logging to /home/<user>/hadoop-2.7.3/logs/hadoop-<user>-namenode-localhost.localdomain.out
localhost: starting datanode, logging to /home/<user>/hadoop-2.7.3/logs/hadoop-<user>-datanode-localhost.localdomain.out
Starting secondary namenodes [0.0.0.0]
0.0.0.0: starting secondarynamenode, logging to /home/<user>/hadoop-2.7.3/logs/hadoop-<user>-secondarynamenode-localhost.localdomain.out

que parece prometedor (comenzando datanode ... sin fallas) - pero el datanode no existía en verdad.

Otra indicación fue ver que no hay ningún nodo de datos en funcionamiento (la siguiente captura de pantalla muestra el estado de trabajo fijo):

He solucionado ese problema haciendo:

rm -rf /tmp/hadoop-<user>/dfs/name
rm -rf /tmp/hadoop-<user>/dfs/data

y luego comienza de nuevo:

sbin/start-dfs.sh
...

Answer 13

Tuve el mismo error en MacOS X 10.7 (hadoop-0.20.2-cdh3u0) debido a que el nodo de datos no se está iniciando.
start-all.sh producido a continuación del resultado:

starting namenode, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
localhost: ssh: connect to host localhost port 22: Connection refused
localhost: ssh: connect to host localhost port 22: Connection refused
starting jobtracker, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
localhost: ssh: connect to host localhost port 22: Connection refused

Después de habilitar el inicio de sesión de ssh a través de System Preferences -> Sharing -> Remote Login , comenzó a funcionar.
start-all.sh salida start-all.sh cambió a following (note start of datanode):

starting namenode, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
Password:
localhost: starting datanode, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
Password:
localhost: starting secondarynamenode, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
starting jobtracker, logging to /java/hadoop-0.20.2-cdh3u0/logs/...
Password:
localhost: starting tasktracker, logging to /java/hadoop-0.20.2-cdh3u0/logs/...

Answer 14

Tuve un problema similar al configurar un clúster de nodo único. Me di cuenta de que no configuré ningún nodo de datos. Agregué mi nombre de host a conf / slaves, luego funcionó. Espero eso ayude.

Answer 15

Y creo que debes asegurarte de que todos los nodos de datos estén activados cuando copies a dfs. En algún caso, lleva un tiempo. Creo que esa es la razón por la cual funciona la solución "verificar el estado de salud", porque vas a la página web del estado de salud y esperas todo, mis cinco centavos.

Answer 16

ADVERTENCIA: lo siguiente destruirá TODOS los datos en HDFS. ¡No ejecute los pasos en esta respuesta a menos que no le importe destruir datos existentes!

Usted debe hacer esto:

1. detener todos los servicios de hadoop
2. eliminar dfs / nombre y dfs / directorios de datos
3. hdfs namenode -format Responde con mayúscula Y
4. iniciar servicios de hadoop

Además, verifique el espacio de disco en su sistema y asegúrese de que los registros no lo adviertan al respecto.