マルチスレッドアプリケーションの一部としてHDFSに書き込もうとすると、次のエラーが表示されます。
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.
私はここで再フォーマットについて最高の回答を試しましたが、これは私には機能しません: HDFSエラー:1ではなく0ノードにのみ複製できました
何が起こっているのですか?
PartitionTextFileWriter
で構成された2つのスレッドで構成されていますスレッド1と2は同じファイルに書き込まれませんが、ディレクトリツリーのルートにある親ディレクトリを共有します。
サーバーのディスク容量に問題はありません。
私はネームノードログにもこれを見ますが、それが何を意味するのか分かりません:
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)
このエラーの原因は何ですか?
ありがとう
このエラーは、フォーカスされたファイル内の特定のブロックのコピーを作成できなかったため、HDFSのブロック複製システムが原因です。その一般的な理由:
またしてください:
参照: https://wiki.Apache.org/hadoop/CouldOnlyBeReplicatedTo
また、以下を確認してください: JavaからHDFSに書き込み、「minReplicationの代わりに0ノードにのみ複製できます」
もう1つの理由は、Datanodeマシンがポート(デフォルトでは50010)を公開していないことです。私の場合、Machine2でホストされているDockerコンテナーC1で実行されているHDFSにMachine1からファイルを書き込もうとしていました。ホストマシンがコンテナで実行されているサービスに要求を転送するには、ポート転送を処理する必要があります。ホストマシンからゲストマシンにポート50010を転送した後、問題を解決できました。
同じエラーが発生しました。hdfsサービスを再起動するとこの問題は解決しました。すなわち、NameNodeおよびDataNodeサービスを再起動しました。
データノードを実行しているコンピューターのjps
コマンドが、データノードが実行されていることを示しているかどうかを確認します。それらが実行されている場合、namenodeに接続できなかったため、namenodeはhadoopシステムにデータノードがないと判断します。
このような場合、start-dfs.sh
を実行した後、マスターノードでnetstat -ntlp
を実行します。 9000は、ほとんどのチュートリアルでcore-site.xml
で指定するように指示されているポート番号です。したがって、netstat
の出力にこのような行が表示される場合
tcp 0 0 120.0.1.1:9000 0.0.0.0:* LISTEN 4209/Java
その後、ホストエイリアスに問題があります。私も同じ問題を抱えていたので、それがどのように解決されたかを述べます。
これは私のcore-site.xml
の内容です
<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://vm-sm:9000</value>
</property>
</configuration>
そのため、マスターコンピューターのvm-sm
エイリアスは127.0.1.1にマップされます。これは、私の/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
マスターシステムのcore-site.xml
が120.0.1.1:9000
にマッピングされているように見えますが、ワーカーノードの192.168.1.1:9000
は接続しようとしています。
そのため、/etc/hosts
ファイルのhadoopシステムのマスターノードのエイリアスを変更する必要がありました(ハイフンを削除しただけです)。
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
core-site.xml
、mapred-site.xml
、およびslave
ファイルの変更を反映しました(マスターの古いエイリアスが発生した場所)。
Hadoopの場所とtmp
フォルダーから古いhdfsファイルを削除し、すべてのノードを再起動すると、問題は解決しました。
現在、netstat -ntlp
は、DFSを開始した後に戻ります
tcp 0 0 192.168.1.1:9000 0.0.0.0:* LISTEN ...
...
私の場合、COLDに設定された出力パスの ストレージポリシー でした。
フォルダーの設定を確認する方法:
hdfs storagepolicies -getStoragePolicy -path my_path
私の場合、それは戻った
The storage policy of my_path
BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}
他の場所(HOTストレージへ)でデータをダンプし、問題はなくなりました。
私も同じエラーが発生し、ブロックサイズを変更しました。これで問題が解決しました。
私の場合、問題はhadoop一時ファイルでした
ログには次のエラーが表示されていました。
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
Hadoop tmpファイルを削除して解決しました
Sudo rm -r /tmp/hadoop-*
HDFSセーフモードを終了できます。
hdfs dfsadmin -safemode forceExit
最近、同様の問題が発生しました。私のデータノード(のみ)にはストレージ用のSSDがあるため、[SSD]file:///path/to/data/dir
構成にdfs.datanode.data.dir
を配置しました。ログにunavailableStorages=[DISK]
が含まれていたため、[SSD]
タグを削除し、問題を解決しました。
どうやら、Hadoopは[DISK]
をデフォルトのストレージタイプとして使用し、[DISK]
タグ付きストレージの場所が利用できない場合、SSDの使用に「フォールバック」(または「フォールアップ」)しません。ただし、この動作についての説明は見つかりませんでした。