wake-up-neo.net

Hadoop: ... wird auf Knoten anstelle von minReplication (= 1) repliziert. Es sind 1 Datanode (n) aktiv und es werden keine Knoten ausgeschlossen

Beim Versuch, als Teil meiner Multithread-Anwendung in HDFS zu schreiben, wird die folgende Fehlermeldung angezeigt

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.

Ich habe die beste Antwort hier versucht, um das Formatieren neu zu formatieren, aber das funktioniert nicht für mich: HDFS-Fehler: konnte nur auf 0 Knoten repliziert werden, anstatt auf 1

Was passiert, ist folgendes:

  1. Meine Anwendung besteht aus 2 Threads, die jeweils mit ihren eigenen Spring Data PartitionTextFileWriter konfiguriert sind.
  2. Thread 1 ist der erste, der Daten verarbeitet, und dieser kann erfolgreich in HDFS schreiben
  3. Sobald Thread 2 jedoch mit der Verarbeitung von Daten beginnt, wird diese Fehlermeldung angezeigt, wenn versucht wird, eine Datei zu leeren

Thread 1 und 2 schreiben nicht in dieselbe Datei, obwohl sie ein übergeordnetes Verzeichnis im Stammverzeichnis meiner Verzeichnisstruktur gemeinsam nutzen.

Es gibt keine Probleme mit dem Speicherplatz auf meinem Server.

Ich sehe das auch in meinen Namensknotenprotokollen, aber nicht sicher, was es bedeutet:

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)

Was könnte die Ursache für diesen Fehler sein?

Vielen Dank

19
DJ180

Dieser Fehler wird durch das Block-Replikationssystem von HDFS verursacht, da es nicht möglich war, Kopien eines bestimmten Blocks in der fokussierten Datei zu erstellen. Häufige Gründe dafür:

  1. Es wird nur eine NameNode-Instanz ausgeführt und befindet sich nicht im abgesicherten Modus
  2. Es sind keine DataNode-Instanzen ausgeführt oder einige sind tot. (Überprüfen Sie die Server)
  3. Namenode- und Datanode-Instanzen werden beide ausgeführt, können jedoch nicht miteinander kommunizieren. Dies bedeutet, dass zwischen DataNode- und NameNode-Instanzen Konnektivitätsprobleme bestehen.
  4. Das Ausführen von DataNode-Instanzen kann nicht mit dem Server kommunizieren, da einige Hadoop-basierte Probleme miteinander verbunden wurden (Protokolle prüfen, die Datenknoteninformationen enthalten).
  5. In konfigurierten Datenverzeichnissen ist kein Festplattenspeicher für DataNode-Instanzen angegeben, oder für DataNode-Instanzen ist nicht genügend Speicherplatz vorhanden. (Überprüfen Sie dfs.data.dir //, falls vorhanden, alte Dateien löschen.)
  6. Angegebene reservierte Bereiche für DataNode-Instanzen in dfs.datanode.du.reserved sind mehr als der freie Speicherplatz, sodass DataNode-Instanzen erkennen können, dass nicht genügend freier Speicherplatz vorhanden ist.
  7. Es gibt nicht genügend Threads für DataNode-Instanzen (überprüfen Sie die Datenprotokolle und den Wert für dfs.datanode.handler.count.)
  8. Stellen Sie sicher, dass dfs.data.transfer.protection nicht gleich "Authentifizierung" ist und dfs.encrypt.data.transfer gleich "true" ist.

Also bitte: 

  • Überprüfen Sie den Status der NameNode- und DataNode-Services und überprüfen Sie die zugehörigen Protokolle
  • Überprüfen Sie, ob core-site.xml den korrekten fs.defaultFS-Wert und hdfs-site.xml einen gültigen Wert hat.
  • Stellen Sie sicher, dass für hdfs-site.xml die Adresse dfs.namenode.http-address .. für alle NameNode-Instanzen angegeben ist, die im Falle einer PHD-HA-Konfiguration angegeben wurden.
  • Überprüfen Sie, ob die Berechtigungen für die Verzeichnisse korrekt sind

Ref: https://wiki.Apache.org/hadoop/CouldOnlyBeReplicatedTo

Ref: https://support.pivotal.io/hc/en-us/articles/201846688-HDFS-reportss-Configured-Capacity-0-0-B-for-datanode

Bitte überprüfen Sie auch: Schreiben von Java in HDFS, das Abrufen von "konnte nur auf 0 Knoten anstelle von minReplication repliziert werden"

12
Eray Balkanli

Ein weiterer Grund könnte sein, dass Ihr Datanode-Computer den Port nicht freigegeben hat (standardmäßig 50010). In meinem Fall habe ich versucht, eine Datei von Maschine1 in HDFS zu schreiben, die auf einem Docker-Container C1 ausgeführt wird, der auf Maschine2 gehostet wurde. Damit der Hostcomputer die Anforderungen an die Dienste weiterleitet, die auf dem Container ausgeführt werden, muss die Portweiterleitung durchgeführt werden. Ich konnte das Problem beheben, nachdem ich den Port 50010 vom Host-Computer zum Gast-Computer weitergeleitet hatte.

2
rishirich

In meinem Fall war dies eine Speicherrichtlinie des Ausgabepfads, die auf COLD gesetzt ist.

So überprüfen Sie die Einstellungen Ihres Ordners:

hdfs storagepolicies -getStoragePolicy -path my_path

In meinem Fall kehrte es zurück

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

Ich habe die Daten an anderer Stelle (zum HOT-Speicher) abgelegt, und das Problem wurde behoben.

1
dupe

Sie können den abgesicherten HDFS-Modus verlassen:

hdfs dfsadmin -safemode forceExit
1
Thomas Decaux

Ich hatte den gleichen Fehler. Beim erneuten Starten der HDFS-Dienste wurde dieses Problem behoben. dh die NameNode- und DataNode-Dienste wurden neu gestartet.

1
Binita Bharati

Überprüfen Sie, ob der Befehl jps auf den Computern, auf denen die Datenanoden ausgeführt werden, anzeigt, dass die Datenanoden ausgeführt werden. Wenn sie ausgeführt werden, bedeutet dies, dass sie keine Verbindung mit dem Namenknoten herstellen konnten. Daher glaubt der Namenknoten, dass es im Hadoop-System keine Datenknoten gibt.

Führen Sie in diesem Fall nach dem Ausführen von start-dfs.shnetstat -ntlp im Master-Knoten aus. 9000 ist die Portnummer, die in den meisten Tutorials in core-site.xml angegeben wird. Wenn Sie also eine solche Zeile in der Ausgabe von netstat sehen

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

dann haben Sie ein Problem mit dem Host-Alias. Ich hatte das gleiche Problem, also werde ich sagen, wie es gelöst wurde.

Dies ist der Inhalt meines core-site.xml

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

Der vm-sm-Alias ​​im Master-Computer entspricht also 127.0.1.1. Dies liegt an der Einrichtung meiner /etc/hosts-Datei.

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

Sieht aus, als schien der core-site.xml des Mastersystems dem 120.0.1.1:9000 zugeordnet zu sein, während der der Worker-Knoten versucht, über 192.168.1.1:9000 eine Verbindung herzustellen.

Also musste ich den Alias ​​des Master-Knotens für das Hadoop-System ändern (den Bindestrich entfernen) in der /etc/hosts-Datei 

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

und spiegelte die Änderung in den Dateien core-site.xml, mapred-site.xml und slave wider (wo immer der alte Alias ​​des Masters aufgetreten ist).

Nach dem Löschen der alten HDFS-Dateien aus dem hadoop-Verzeichnis sowie dem Ordner tmp und dem Neustart aller Knoten wurde das Problem behoben.

Nun wird netstat -ntlp nach dem Start von DFS zurückgegeben 

tcp        0      0 192.168.1.1:9000        0.0.0.0:*               LISTEN ...
...
1
Ébe Isaac

Ich hatte kürzlich ein ähnliches Problem. Da meine Datanodes (nur) SSDs zum Speichern hatten, habe ich [SSD]file:///path/to/data/dir für die dfs.datanode.data.dir-Konfiguration angegeben. Aufgrund der Protokolle mit unavailableStorages=[DISK] entfernte ich das [SSD]-Tag, wodurch das Problem behoben wurde.

Offensichtlich verwendet Hadoop [DISK] als Standardspeichertyp und verwendet die SSD nicht als "Fallback" (bzw. "Fallup"), wenn kein mit [DISK] gekennzeichneter Speicherort verfügbar ist. Ich konnte jedoch keine Dokumentation zu diesem Verhalten finden.

1
Tw UxTLi51Nus

Ich hatte auch den gleichen Fehler, dann habe ich die Blockgröße geändert. Dies kam, um das Problem zu lösen.

0

In meinem Fall lag das Problem bei temporären Hadoop-Dateien

Die Protokolle zeigten den folgenden Fehler:

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 [email protected]
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

Ich löste das Entfernen von hadoop tmp-Dateien

Sudo rm -r /tmp/hadoop-*
0
felipeek