执行start-dfs.sh后，datenode没有启动的最全解决办法（全网最全）

前言

在Hadoop中申请一个Flink的Session会话的时候出现了报错

报错内容

File /user/.flink/application_1723473994699_0002b/flink-table-api-java-uber-1.17.0.jar could only be written to 0 of the 1 minReplication nodes. There are 0 datanode(s) running and 0 node(s) are excluded in this operation.

看到说没有找到datanode,然后我就去检查了一下进程，发现确实没有看到datanode，在使用start-dfs.sh的时候，datanode没有启动

排查问题

可以通过以下来排查一下问题的原因

1. 检查 Hadoop 日志文件： DataNode 的日志文件通常位于 HADOOP_LOG_DIR/hadoop-datanode-<username>.log（
2. 检查 Hadoop 配置文件：
   • 确保 hdfs-site.xml 和 core-site.xml 文件中的配置是正确的。特别是与 DataNode 相关的配置，如 dfs.datanode.data.dir（DataNode 存储数据的目录）。
   • 确保 DataNode 的端口（默认是 50010）没有被其他进程占用。
3. 检查 DataNode 存储目录：
   • DataNode 的存储目录（由 dfs.datanode.data.dir 配置）必须存在且可写。如果目录不存在或没有写权限，DataNode 将无法启动。
   • 如果之前 DataNode 进程异常终止，可能会留下一些锁文件或临时文件。这些文件有时会阻止 DataNode 重新启动。尝试清理这些文件（但请小心操作，以免丢失数据）。
4. 检查 NameNode 的状态：
   • DataNode 需要与 NameNode 通信才能正常工作。如果 NameNode 没有运行或无法响应，DataNode 也将无法启动。
   • 使用 jps 命令查看 NameNode 进程是否正在运行。
5. 检查网络配置：
   • 确保 DataNode 能够通过网络与 NameNode 通信。检查防火墙和网络配置，确保没有阻止 DataNode 和 NameNode 之间的通信。
6. 重新启动 HDFS：
   • 如果上述步骤都无法解决问题，尝试停止并重新启动整个 HDFS 集群（使用 stop-dfs.sh 和 start-dfs.sh）。
7. 查看 Hadoop 集群的健康报告：
   • 使用 Hadoop 的 Web UI（通常通过 NameNode 的 HTTP 端口访问，默认是 50070）来查看集群的健康报告和状态信息。
8. 查看系统日志：
   • 检查系统日志文件（如 /var/log/syslog/var/log/messages 或类似文件），以查找可能与 Hadoop 进程相关的错误或警告。
9. 检查namenode跟datanode的clusterID是否一致

我的问题clusterID不一致

我去检查了一下namenode跟datanode的clusterID是否一致，发现两者确实不一样

namenode

clusterID=CID-c31bfe11-654c-4b08-a555-22de9305b6dd

datanode

clusterID=CID-b4ac40db-530a-4b2d-8278-0bfe8b91de28

为什么clusterID会不一样？

clusterID不一致通常发生在以下几种情况：

1. 重新格式化NameNode：如果NameNode被重新格式化（例如，使用hdfs namenode -format命令），而DataNode没有被相应地重置或格式化，那么NameNode将获得一个新的clusterID，而DataNode仍然保留旧的clusterID。
2. 从备份恢复NameNode：如果NameNode是从备份中恢复的，并且该备份与当前运行的DataNode集不属于同一个集群（即clusterID不匹配），那么也会出现clusterID不一致的情况。
3. 多集群环境混淆：在多个HDFS集群共存的环境中，如果配置文件或启动脚本被错误地配置或使用，可能会导致DataNode连接到错误的NameNode，从而出现clusterID不一致。

clusterID不一致的后果

当NameNode和DataNode的clusterID不一致时，DataNode将无法与NameNode成功通信或注册自己为集群的一部分。这会导致以下后果：

• 数据不可见：由于DataNode无法与NameNode通信，存储在DataNode上的数据将对HDFS用户不可见。
• 集群不稳定：DataNode可能会持续尝试与NameNode通信，但由于clusterID不匹配而失败，这可能导致集群状态不稳定或DataNode频繁重启。
• 数据丢失风险：如果DataNode在不知道的情况下继续写入数据（尽管这种情况较少见，因为通常DataNode会检查与NameNode的兼容性），那么这些数据可能会与NameNode的元数据不同步，从而导致数据丢失的风险增加。

如何解决clusterID不一致的问题

1. 重新格式化NameNode并重置DataNode：如果可能的话，最简单的方法是停止HDFS集群，重新格式化NameNode，并删除或重置所有DataNode的存储目录。然后重新启动HDFS集群。注意，这将删除集群中的所有数据。
2. 从备份恢复：如果有可用的NameNode备份，并且它与当前运行的DataNode集属于同一个集群（即clusterID匹配），则可以从该备份恢复NameNode。
3. 手动同步clusterID：在某些情况下，如果确信DataNode属于当前集群，但仅由于某种原因clusterID不匹配，可以尝试手动更改DataNode的clusterID以与NameNode的clusterID相匹配。然而，这种方法需要谨慎操作，并且可能涉及对HDFS内部结构的直接修改。
4. 检查配置和日志：仔细检查HDFS的配置文件和日志文件，以查找可能导致clusterID不一致的配置错误或操作失误。

总之，clusterID不一致是HDFS集群中一个严重的问题，需要仔细诊断和解决。在大多数情况下，最好的做法是避免重新格式化NameNode，除非确实需要重置整个集群。

解决方案

最好的解决方案还是最好手动修改一下DataNode的clusterID，修改成跟NameNode一致

首先找到VERSION文件，NameNode跟DataNode都有自己的VERSON文件，里面存放着clusterID，但是Hadoop版本的不同，二者存放的路径也不相同

这里建议大家直接使用搜索功能就好了，方便快捷

首先进入到Hadoop目录下,使用find在Hadoop目录下以及其子目录下寻找VERSION

find -name VERSION

我这里找到了三个

./data/dfs/data/current/VERSION
./data/dfs/data/current/BP-1238583945-192.168.10.102-1709627934929/current/VERSION
./data/dfs/name/current/VERSION

第一个可以看到是在data目录下，那么就是datanode的VERSION文件了

第二个应该是一个映射文件，就先不去管它

第三个可以看到是在name目录下，那么就是namenode的VERSION文件了

首先关闭hdfs

stop-dfs.sh

然后检查namenode跟datanode中两个VERSION文件中的clusterID是否一致，如果不一致的话，手动修改DataNode中的clusterID，修改成跟namenode一样的就可以了

然后启动hdfs

start-dfs.sh

DataNode已经正常启动