Erreur HDFS : la réplication n'a pu se faire que sur 0 nœud, au lieu de 1.

Question

J'ai créé un cluster hadoop à un seul nœud sous Ubuntu dans EC2.

Le test d'un simple téléchargement de fichier vers hdfs fonctionne depuis la machine EC2, mais ne fonctionne pas depuis une machine en dehors d'EC2.

Je peux parcourir le système de fichiers via l'interface web à partir de la machine distante, et il montre un datanode qui est signalé comme étant en service. J'ai ouvert tous les ports tcp dans la sécurité de 0 à 60000( !) donc je ne pense pas que ce soit ça.

Je reçois l'erreur

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)

Le journal de namenode donne juste la même erreur. Les autres ne semblent pas avoir quelque chose d'intéressant

Des idées ?

Cheers

Answer 1

AVERTISSEMENT : Ce qui suit va détruire TOUTES les données sur HDFS. N'exécutez pas les étapes de cette réponse à moins que vous ne vous souciiez pas de la destruction des données existantes !

Vous devriez le faire :

1. arrêter tous les services hadoop
2. supprimer les répertoires dfs/name et dfs/data
3. hdfs namenode -format Réponse avec un Y majuscule
4. démarrer les services hadoop

Vérifiez également l'espace disque de votre système et assurez-vous que les journaux ne vous avertissent pas à ce sujet.

Answer 2

C'est votre problème - le client ne peut pas communiquer avec le Datanode. Parce que l'IP que le client a reçu pour le Datanode est une IP interne et non l'IP publique. Jetez un coup d'oeil à ceci

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

Regardez le code source 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;
}

Ce qu'il faut comprendre ici, c'est que Namenode ne fournit que la liste des Datanodes pour stocker les blocs. Namenode n'écrit pas les données dans les Datanodes. C'est le travail du Client d'écrire les données aux Datanodes en utilisant le DFSOutputStream . Avant que toute écriture puisse commencer, le code ci-dessus s'assure que le Client peut communiquer avec le(s) Datanode(s) et si la communication échoue avec le Datanode, le Datanode est ajouté aux excludedNodes .

Answer 3

Regardez ce qui suit :

En voyant cette exception (ne pouvait être répliqué à 0 nœuds, au lieu de 1), le nœud de données n'est pas disponible pour le nœud de nom .

Il s'agit des cas suivants Le nœud de données peut ne pas être disponible pour le nœud de nom.

1. Le disque du nœud de données est plein

2. Le nœud de données est occupé par le rapport et le balayage des blocs.

3. Si la taille du bloc est une valeur négative (dfs.block.size dans hdfs-site.xml)

4. pendant que l'écriture est en cours, le nœud de données primaire tombe en panne (toute fluctuation entre les machines du nœud de nom et du nœud de données).

5. quand jamais nous ajoutons un morceau partiel et appelons sync pour les ajouts suivants de morceaux partiels, le client doit stocker les données précédentes dans le tampon.

Par exemple, après avoir ajouté "a", j'ai appelé sync et lorsque j'essaie d'ajouter le tampon devrait contenir "ab".

Et côté serveur, lorsque le chunk n'est pas multiple de 512, il essaiera de faire une comparaison Crc pour les données présentes dans le fichier de bloc ainsi que le Crc présent dans le métafichier. Mais en construisant le Crc pour les données présentes dans le bloc, il compare toujours jusqu'à l'Offset initial ou pour plus d'analyse, veuillez consulter les logs du nœud de données.

Référence : http://www.mail-archive.com/hdfs-user@hadoop.apache.org/msg01374.html

Answer 4

J'ai eu un problème similaire lors de la mise en place d'un cluster à un seul nœud. J'ai réalisé que je n'avais pas configuré de nœud de données. J'ai ajouté mon nom d'hôte à conf/slaves, puis ça a marché. J'espère que cela vous aidera.

Answer 5

J'ai eu la même erreur sur MacOS X 10.7 (hadoop-0.20.2-cdh3u0) à cause du nœud de données qui ne démarre pas.
start-all.sh a produit le résultat suivant :

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

Après avoir activé la connexion ssh via System Preferences -> Sharing -> Remote Login ça a commencé à fonctionner.
start-all.sh la sortie a été modifiée comme suit (notez le début du 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/...