我也有同样的错误，重新启动hdfs服务解决了这个问题。ie重新启动了namenode和datanode服务。

在我的例子中，问题是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

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

此错误是由hdfs的块复制系统引起的，因为它无法在聚焦文件中制作特定块的任何副本。常见原因：
只有namenode示例正在运行，并且它不在安全模式下
没有datanode示例启动并运行，或者有些示例已死亡(检查服务器）
namenode和datanode示例都在运行，但是它们不能相互通信，这意味着datanode和namenode示例之间存在连接问题。
由于一些基于hadoop的网络问题（检查包含datanode信息的日志），正在运行的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地址。。对于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
另外，请检查：从java写入hdfs，获取“只能复制到0个节点，而不是minreplication”

在我的例子中，它是一个输出路径设置为cold的存储策略。
如何检查文件夹的设置：

hdfs storagepolicies -getStoragePolicy -path my_path

就我而言，它回来了

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

我把数据丢到别的地方（热存储），问题就消失了。

检查 jps 运行datanodes的计算机上的命令显示datanodes正在运行。如果它们正在运行，则意味着它们无法与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 主计算机中的别名Map到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 .
因此，我必须更改hadoop系统主节点的别名（刚刚删除了连字符） /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

并反映了 core-site.xml , mapred-site.xml ，和 slave 文件（无论主服务器的旧别名出现在何处）。
从hadoop位置删除旧的hdfs文件以及 tmp 文件夹并重新启动所有节点，问题就解决了。
现在， netstat -ntlp 启动dfs后返回

tcp        0      0 192.168.1.1:9000        0.0.0.0:*               LISTEN ...
...

由于数据节点未运行，出现此错误。在vm上解决此问题
已删除名称/数据节点目录
重新创建目录
格式化名称节点和数据节点（不是必需的）hadoop namenode-format
重新启动服务start-dfs.sh
现在jps显示name&data节点和sqoop作业都成功地工作了

另一个原因可能是您的datanode计算机没有公开端口（默认情况下为50010）。在我的例子中，我试图将一个文件从machine1写入在machine2上托管的docker容器c1上运行的hdfs。对于要将请求转发到容器上运行的服务的主机，应该注意端口转发。在将端口50010从主机转发到访客机之后，我可以解决此问题。

我最近也有类似的问题。由于我的datanodes（仅）有ssd用于存储，我将 [SSD]file:///path/to/data/dir 对于 dfs.datanode.data.dir 配置。由于日志中包含 unavailableStorages=[DISK] 我移除了 [SSD] 标签，解决了问题。
显然，hadoop使用 [DISK] 作为默认存储类型，如果没有，则不“回退”（或者更确切地说是“回退”）使用ssd [DISK] 标记的存储位置可用。不过，我找不到任何关于这种行为的文件。