web-dev-qa-db-ja.com

Hadoop:... minReplication(= 1)の代わりに0ノードに複製されます。 1つのデータノードが実行されており、この操作で除外されるノードはありません

マルチスレッドアプリケーションの一部として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ノードにのみ複製できました

何が起こっているのですか?

  1. 私のアプリケーションは、それぞれが独自のSpring Data PartitionTextFileWriterで構成された2つのスレッドで構成されています
  2. スレッド1は最初にデータを処理し、これによりHDFSに正常に書き込むことができます
  3. ただし、スレッド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)

このエラーの原因は何ですか?

ありがとう

24
DJ180

このエラーは、フォーカスされたファイル内の特定のブロックのコピーを作成できなかったため、HDFSのブロック複製システムが原因です。その一般的な理由:

  1. NameNodeインスタンスのみが実行されており、セーフモードではありません
  2. DataNodeインスタンスが稼働していないか、一部が停止しています。 (サーバーを確認してください)
  3. NamenodeインスタンスとDatanodeインスタンスは両方とも実行されていますが、相互に通信できません。つまり、DataNodeインスタンスとNameNodeインスタンスの間に接続の問題があります。
  4. 実行中のDataNodeインスタンスは、hadoopベースの問題のネットワークのためにサーバーと通信できません(datanode情報を含むログを確認してください)
  5. DataNodeインスタンスの構成済みデータディレクトリに指定されたハードディスク領域がないか、DataNodeインスタンスの領域が不足しています。 (dfs.data.dirを確認//古いファイルがあれば削除します)
  6. Dfs.datanode.du.reservedのDataNodeインスタンスに指定された予約スペースは、十分な空きスペースがないことをDataNodeインスタンスに認識させる空きスペース以上です。
  7. DataNodeインスタンスに十分なスレッドがありません(datanodeログとdfs.datanode.handler.count値を確認してください)
  8. Dfs.data.transfer.protectionが「認証」と等しくなく、dfs.encrypt.data.transferがtrueと等しいことを確認してください。

またしてください:

  • NameNodeおよびDataNodeサービスのステータスを確認し、関連するログを確認します
  • Core-site.xmlに正しいfs.defaultFS値があり、hdfs-site.xmlに有効な値があるかどうかを確認します。
  • PHD HA構成の場合に指定されたすべてのNameNodeインスタンスについて、hdfs-site.xmlにdfs.namenode.http-address ..があることを確認します。
  • ディレクトリのアクセス許可が正しいかどうかを確認します

参照: https://wiki.Apache.org/hadoop/CouldOnlyBeReplicatedTo

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

また、以下を確認してください: JavaからHDFSに書き込み、「minReplicationの代わりに0ノードにのみ複製できます」

17
Eray Balkanli

もう1つの理由は、Datanodeマシンがポート(デフォルトでは50010)を公開していないことです。私の場合、Machine2でホストされているDockerコンテナーC1で実行されているHDFSにMachine1からファイルを書き込もうとしていました。ホストマシンがコンテナで実行されているサービスに要求を転送するには、ポート転送を処理する必要があります。ホストマシンからゲストマシンにポート50010を転送した後、問題を解決できました。

2
rishirich

同じエラーが発生しました。hdfsサービスを再起動するとこの問題は解決しました。すなわち、NameNodeおよびDataNodeサービスを再起動しました。

2
Binita Bharati

データノードを実行しているコンピューターの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.xml120.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.xmlmapred-site.xml、およびslaveファイルの変更を反映しました(マスターの古いエイリアスが発生した場所)。

Hadoopの場所とtmpフォルダーから古いhdfsファイルを削除し、すべてのノードを再起動すると、問題は解決しました。

現在、netstat -ntlpは、DFSを開始した後に戻ります

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

私の場合、COLDに設定された出力パスの ストレージポリシー でした。

フォルダーの設定を確認する方法:

hdfs storagepolicies -getStoragePolicy -path my_path

私の場合、それは戻った

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

他の場所(HOTストレージへ)でデータをダンプし、問題はなくなりました。

1
dupe

私も同じエラーが発生し、ブロックサイズを変更しました。これで問題が解決しました。

1

私の場合、問題は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-*
1
felipeek

HDFSセーフモードを終了できます。

hdfs dfsadmin -safemode forceExit
1
Thomas Decaux

最近、同様の問題が発生しました。私のデータノード(のみ)にはストレージ用のSSDがあるため、[SSD]file:///path/to/data/dir構成にdfs.datanode.data.dirを配置しました。ログにunavailableStorages=[DISK]が含まれていたため、[SSD]タグを削除し、問題を解決しました。

どうやら、Hadoopは[DISK]をデフォルトのストレージタイプとして使用し、[DISK]タグ付きストレージの場所が利用できない場合、SSDの使用に「フォールバック」(または「フォールアップ」)しません。ただし、この動作についての説明は見つかりませんでした。

1
Tw UxTLi51Nus