Hadoop: ... être répliqué sur les noeuds au lieu de minReplication (= 1). Il y a 1 datanode en cours d'exécution et aucun nœud n'est exclu de cette opération
Je reçois le message d'erreur suivant lorsque j'essaie d'écrire sur HDFS dans le cadre de mon application multithread
could only be replicated to 0 nodes instead of minReplication (=1). There are 1 datanode(s) running and no node(s) are excluded in this operation.
J'ai essayé la réponse la mieux notée ici concernant le reformatage mais cela ne fonctionne pas pour moi: erreur HDFS: ne peut être répliqué que sur 0 nœud au lieu de 1
Qu'est-ce qui se passe est la suivante:
- Mon application est composée de 2 threads chacun configuré avec leurs propres données de printemps
PartitionTextFileWriter - Le fil 1 est le premier à traiter les données, ce qui permet d’écrire avec succès sur HDFS.
- Cependant, une fois que le thread 2 commence à traiter les données, j'obtiens cette erreur lorsqu'il tente de vider un fichier
Les threads 1 et 2 n'écriront pas dans le même fichier, bien qu'ils partagent un répertoire parent à la racine de mon arborescence.
Il n'y a pas de problèmes d'espace disque sur mon serveur.
Je vois aussi cela dans les journaux de mon nom, mais je ne sais pas ce que cela signifie:
2016-03-15 11:23:12,149 WARN org.Apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 1 (unavailableStorages=[], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) For more information, please enable DEBUG log level on org.Apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy
2016-03-15 11:23:12,150 WARN org.Apache.hadoop.hdfs.protocol.BlockStoragePolicy: Failed to place enough replicas: expected size is 1 but only 0 storage types can be selected (replication=1, selected=[], unavailable=[DISK], removed=[DISK], policy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]})
2016-03-15 11:23:12,150 WARN org.Apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 1 (unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) All required storage types are unavailable: unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}
2016-03-15 11:23:12,151 INFO org.Apache.hadoop.ipc.Server: IPC Server handler 8 on 9000, call org.Apache.hadoop.hdfs.protocol.ClientProtocol.addBlock from 10.104.247.78:52004 Call#61 Retry#0
Java.io.IOException: File /metrics/abc/myfile could only be replicated to 0 nodes instead of [2016-03-15 13:34:16,663] INFO [Group Metadata Manager on Broker 0]: Removed 0 expired offsets in 1 milliseconds. (kafka.coordinator.GroupMetadataManager)
Quelle pourrait être la cause de cette erreur?
Merci
Cette erreur est due au système de réplication de blocs de HDFS, car il n’a pas pu créer de copies d’un bloc spécifique dans le fichier ciblé. Les raisons communes de cela:
- Seule une instance NameNode est en cours d'exécution et elle n'est pas en mode sans échec.
- Aucune instance DataNode n'est en cours d'exécution ou certaines sont mortes. (Vérifiez les serveurs)
- Les instances Namenode et Datanode sont toutes les deux en cours d'exécution, mais elles ne peuvent pas communiquer entre elles, ce qui signifie qu'il existe un problème de connectivité entre les instances DataNode et NameNode.
- Les instances en cours d'exécution DataNode ne peuvent pas communiquer avec le serveur en raison de problèmes liés à la mise en réseau de hadoop (les journaux de contrôle contenant des informations datanode)
- Aucun espace de disque dur n'est spécifié dans les répertoires de données configurés pour les instances DataNode ou les instances DataNode sont à court d'espace. (cochez dfs.data.dir // supprime les anciens fichiers, le cas échéant)
- Les espaces réservés spécifiés pour les instances DataNode dans dfs.datanode.du.reserved sont plus que l’espace libre, ce qui permet aux instances DataNode de comprendre qu’il n’ya pas assez d’espace libre.
- Il n'y a pas assez de threads pour les instances DataNode (consultez les journaux de datanode et la valeur dfs.datanode.handler.count)
- Assurez-vous que dfs.data.transfer.protection n'est pas égal à «authentication» et que dfs.encrypt.data.transfer est égal à true.
Aussi s'il vous plaît:
- Vérifier le statut des services NameNode et DataNode et consulter les journaux associés
- Vérifiez si le fichier core-site.xml a la valeur fs.defaultFS correcte et si hdfs-site.xml a une valeur valide.
- Vérifiez que le fichier hdfs-site.xml contient dfs.namenode.http-address .. pour toutes les instances NameNode spécifiées dans le cas d'une configuration PHD HA.
- Vérifiez si les autorisations sur les répertoires sont correctes
Réf.: https://wiki.Apache.org/hadoop/CouldOnlyBeReplicatedTo
Vérifiez également: L'écriture sur HDFS à partir de Java, "ne peut être répliquée que sur 0 nœud au lieu de minReplication"
Dans mon cas, il s'agissait d'une politique de stockage du chemin de sortie défini sur COLD.
Comment vérifier les paramètres de votre dossier:
hdfs storagepolicies -getStoragePolicy -path my_path
Dans mon cas, il est revenu
The storage policy of my_path
BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}
J'ai vidé les données ailleurs (vers stockage HOT) et le problème a disparu.
Vous pouvez quitter le mode sans échec HDFS:
hdfs dfsadmin -safemode forceExit
J'ai eu la même erreur, le redémarrage des services HDFS a résolu ce problème. c'est-à-dire que les services NameNode et DataNode ont été redémarrés.
Vérifiez si la commande jps sur les ordinateurs qui exécutent les codes de données indique que les codes de données sont en cours d'exécution. S'ils fonctionnent, cela signifie qu'ils ne peuvent pas se connecter avec le namenode et par conséquent, le namenode pense qu'il n'y a pas de datanodes dans le système hadoop.
Dans ce cas, après avoir exécuté start-dfs.sh, exécutez netstat -ntlp dans le nœud maître. 9000 est le numéro de port que la plupart des tutoriels vous indiquent de spécifier dans core-site.xml. Donc, si vous voyez une ligne comme celle-ci dans la sortie de netstat
tcp 0 0 120.0.1.1:9000 0.0.0.0:* LISTEN 4209/Java
alors vous avez un problème avec l'alias de l'hôte. J'ai eu le même problème, alors je vais expliquer comment le problème a été résolu.
Ceci est le contenu de mon core-site.xml
<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://vm-sm:9000</value>
</property>
</configuration>
Ainsi, l'alias vm-sm de l'ordinateur maître est mappé sur 127.0.1.1. Ceci est dû à la configuration de mon fichier /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
Il semble que le core-site.xml du système maître semble s'être mappé sur le 120.0.1.1:9000 alors que celui des nœuds de travail tente de se connecter via 192.168.1.1:9000.
J'ai donc dû changer l'alias du noeud principal pour le système hadoop (le trait d'union vient d'être supprimé) dans le fichier /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
et reflète le changement dans les fichiers core-site.xml, mapred-site.xml et slave (quel que soit l'ancien alias du maître).
Après avoir supprimé les anciens fichiers hdfs de l'emplacement hadoop ainsi que le dossier tmp et redémarré tous les nœuds, le problème a été résolu.
Maintenant, netstat -ntlp après le début des déclarations DFS
tcp 0 0 192.168.1.1:9000 0.0.0.0:* LISTEN ...
...
J'ai eu un problème similaire récemment. Comme mes datanodes (uniquement) avaient des disques SSD pour le stockage, je mets [SSD]file:///path/to/data/dir pour la configuration dfs.datanode.data.dir. En raison des journaux contenant unavailableStorages=[DISK], j'ai supprimé la balise [SSD], qui a résolu le problème.
Apparemment, Hadoop utilise [DISK] comme type de stockage par défaut et ne «se replie» pas (ou plutôt ne «replie») sur l'utilisation de SSD si aucun emplacement de stockage marqué [DISK] n'est disponible. Je n'ai pu trouver aucune documentation sur ce comportement cependant.
Moi aussi j'ai eu la même erreur, alors j'ai changé la taille du bloc. Ceci est venu pour résoudre le problème.
Dans mon cas, le problème était les fichiers temporaires hadoop
Les journaux montraient l'erreur suivante:
2019-02-27 13:52:01,079 INFO org.Apache.hadoop.hdfs.server.common.Storage: Lock on /tmp/hadoop-i843484/dfs/data/in_use.lock acquired by nodename 28111@slel00681841a
2019-02-27 13:52:01,087 WARN org.Apache.hadoop.hdfs.server.common.Storage: Java.io.IOException: Incompatible clusterIDs in /tmp/hadoop-i843484/dfs/data: namenode clusterID = CID-38b0104b-d3d2-4088-9a54-44b71b452006; datanode clusterID = CID-8e121bbb-5a08-4085-9817-b2040cd399e1
J'ai résolu en supprimant les fichiers hadoop tmp
Sudo rm -r /tmp/hadoop-*