Question

尝试写入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 error: could only be replicated to 0 nodes, instead of 1

这是怎么回事：

我的应用程序由2个线程组成，每个线程都配置了自己的Spring Data PartitionTextFileWriter
线程1是第一个处理数据，这可以成功写入HDFS
但是，一旦线程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)

导致此错误的原因是什么？

由于

Answer 1

此错误是由HDFS的块复制系统引起的，因为它无法在聚焦文件中设置特定块的任何副本。常见原因：

只有NameNode实例正在运行且它不在安全模式下
没有DataNode实例启动并运行，或者有些实例已经死亡。（检查服务器）
Namenode和Datanode实例都在运行，但它们无法相互通信，这意味着DataNode和NameNode实例之间存在连接问题。
运行DataNode实例无法与服务器通信，因为有一些基于hadoop的问题的联网（检查包含datanode信息的日志）
在DataNode实例的已配置数据目录中没有指定硬盘空间，或者DataNode实例的空间不足。（检查dfs.data.dir //删除旧文件，如果有的话）
dfs.datanode.du.reserved中为DataNode实例指定的保留空间超过了使DataNode实例理解没有足够空间的可用空间。
DataNode实例没有足够的线程（检查datanode日志和dfs.datanode.handler.count值）
确保dfs.data.transfer.protection不等于“authentication”，dfs.encrypt.data.transfer等于true。

还请：

验证NameNode和DataNode服务的状态并检查相关日志
验证core-site.xml是否具有正确的fs.defaultFS值且hdfs-site.xml是否具有有效值。
验证hdfs-site.xml是否有dfs.namenode.http-address ..用于在PHD HA配置情况下指定的所有NameNode实例。
验证目录的权限是否正确

参考：https://wiki.apache.org/hadoop/CouldOnlyBeReplicatedTo

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

另外，请检查：Writing to HDFS from Java, getting "could only be replicated to 0 nodes instead of minReplication"

Answer 2

我最近遇到过类似的问题。由于我的datanodes（仅）具有用于存储的SSD，因此我将[SSD]file:///path/to/data/dir用于dfs.datanode.data.dir配置。由于包含unavailableStorages=[DISK]的日志，我删除了[SSD]标记，从而解决了问题。

显然，Hadoop使用[DISK]作为默认存储类型，并且不会后退＆＃39; （如果没有[DISK]标记的存储位置可用，则使用SSD（或者更确切地说是＆＃39; fallup＆＃39;）。我找不到关于这种行为的任何文件。

Answer 3

检查运行数据节点的计算机上的jps命令是否显示数据节点正在运行。如果它们正在运行，则意味着它们无法与namenode连接，因此namenode认为hadoop系统中没有datanode。

在这种情况下，运行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进行连接。

所以我必须更改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文件中hadoop系统的主节点的别名（刚刚删除了连字符）

core-site.xml

并反映了mapred-site.xml，slave和tmp文件的变化（无论主要旧别名发生在何处）。

从hadoop位置删除旧的hdfs文件以及netstat -ntlp文件夹并重新启动所有节点后，问题就解决了。

现在，启动DFS后tcp 0 0 192.168.1.1:9000 0.0.0.0:* LISTEN ... ...返回

require 'time'
puts "Enter the time"
a = gets.chomp
p Time.parse(":#{a}").strftime("%H:%M:%S")

Answer 4

我遇到了同样的错误，重新启动hdfs服务解决了此问题。即重新启动NameNode和DataNode服务。

Answer 5

在我的情况下，这是将storage policy的输出路径设置为COLD。

如何检查文件夹设置：

hdfs storagepolicies -getStoragePolicy -path my_path

就我而言，它返回了

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

我将数据转储到其他地方（到HOT存储），问题就消失了。

Answer 6

您可以退出HDFS安全模式：

hdfs dfsadmin -safemode forceExit

Answer 7

在我的情况下，问题是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-*

Answer 8

另一个原因可能是您的Datanode机器没有暴露该端口（默认为50010）。就我而言，我试图将文件从Machine1写入HDFS，该文件运行在Machine2上托管的Docker容器C1上。为了使主机将请求转发到容器上运行的服务，应注意端口转发。将端口50010从主机转发到客户机后，我可以解决此问题。

Answer 9

我也有同样的错误，然后我更改了块大小。这是为了解决问题。

Answer 10

由于该数据节点未运行，因此得到了此错误。要在VM上解决此问题

已删除的名称/数据节点目录
重新创建目录
格式化名称节点和数据节点（非必填）hadoop namenode -format
重新启动服务start-dfs.sh
现在jps可以同时显示“名称和数据”节点和Sqoop作业成功

Hadoop：...被复制到0个节点而不是minReplication（= 1）。有1个datanode正在运行，并且此操作中不排除任何节点

10 个答案: