前言
在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没有启动
排查问题
可以通过以下来排查一下问题的原因
- 检查 Hadoop 日志文件：
- DataNode 的日志文件通常位于
$HADOOP_LOG_DIR/hadoop-datanode-<username>.log（$HADOOP_LOG_DIR是 Hadoop 配置的日志目录，默认可能是$HADOOP_HOME/logs）。查看这个文件以获取启动失败的具体错误信息。
- 检查 Hadoop 配置文件：
- 确保
hdfs-site.xml和core-site.xml文件中的配置是正确的。特别是与 DataNode 相关的配置，如dfs.datanode.data.dir（DataNode 存储数据的目录）。 - 确保 DataNode 的端口（默认是 50010）没有被其他进程占用。
- 检查 DataNode 存储目录：
- DataNode 的存储目录（由
dfs.datanode.data.dir配置）必须存在且可写。如果目录不存在或没有写权限，DataNode 将无法启动。 - 如果之前 DataNode 进程异常终止，可能会留下一些锁文件或临时文件。这些文件有时会阻止 DataNode 重新启动。尝试清理这些文件（但请小心操作，以免丢失数据）。
- 检查 NameNode 的状态：
- DataNode 需要与 NameNode 通信才能正常工作。如果 NameNode 没有运行或无法响应，DataNode 也将无法启动。
- 使用
jps命令查看 NameNode 进程是否正在运行。
- 检查网络配置：
- 确保 DataNode 能够通过网络与 NameNode 通信。检查防火墙和网络配置，确保没有阻止 DataNode 和 NameNode 之间的通信。
- 重新启动 HDFS：
- 如果上述步骤都无法解决问题，尝试停止并重新启动整个 HDFS 集群（使用
stop-dfs.sh和start-dfs.sh）。
- 查看 Hadoop 集群的健康报告：
- 使用 Hadoop 的 Web UI（通常通过 NameNode 的 HTTP 端口访问，默认是 50070）来查看集群的健康报告和状态信息。
- 查看系统日志：
- 检查系统日志文件（如
/var/log/syslog/var/log/messages或类似文件），以查找可能与 Hadoop 进程相关的错误或警告。
- 检查namenode跟datanode的clusterID是否一致
我的问题clusterID不一致
我去检查了一下namenode跟datanode的clusterID是否一致，发现两者确实不一样
namenode
clusterID=CID-c31bfe11-654c-4b08-a555-22de9305b6dddatanode
clusterID=CID-b4ac40db-530a-4b2d-8278-0bfe8b91de28为什么clusterID会不一样？
clusterID不一致通常发生在以下几种情况：
- 重新格式化NameNode：如果NameNode被重新格式化（例如，使用
hdfs namenode -format命令），而DataNode没有被相应地重置或格式化，那么NameNode将获得一个新的clusterID，而DataNode仍然保留旧的clusterID。 - 从备份恢复NameNode：如果NameNode是从备份中恢复的，并且该备份与当前运行的DataNode集不属于同一个集群（即
clusterID不匹配），那么也会出现clusterID不一致的情况。 - 多集群环境混淆：在多个HDFS集群共存的环境中，如果配置文件或启动脚本被错误地配置或使用，可能会导致DataNode连接到错误的NameNode，从而出现
clusterID不一致。
clusterID不一致的后果
当NameNode和DataNode的clusterID不一致时，DataNode将无法与NameNode成功通信或注册自己为集群的一部分。这会导致以下后果：
- 数据不可见：由于DataNode无法与NameNode通信，存储在DataNode上的数据将对HDFS用户不可见。
- 集群不稳定：DataNode可能会持续尝试与NameNode通信，但由于
clusterID不匹配而失败，这可能导致集群状态不稳定或DataNode频繁重启。 - 数据丢失风险：如果DataNode在不知道的情况下继续写入数据（尽管这种情况较少见，因为通常DataNode会检查与NameNode的兼容性），那么这些数据可能会与NameNode的元数据不同步，从而导致数据丢失的风险增加。
如何解决clusterID不一致的问题
- 重新格式化NameNode并重置DataNode：如果可能的话，最简单的方法是停止HDFS集群，重新格式化NameNode，并删除或重置所有DataNode的存储目录。然后重新启动HDFS集群。注意，这将删除集群中的所有数据。
- 从备份恢复：如果有可用的NameNode备份，并且它与当前运行的DataNode集属于同一个集群（即
clusterID匹配），则可以从该备份恢复NameNode。 - 手动同步
clusterID：在某些情况下，如果确信DataNode属于当前集群，但仅由于某种原因clusterID不匹配，可以尝试手动更改DataNode的clusterID以与NameNode的clusterID相匹配。然而，这种方法需要谨慎操作，并且可能涉及对HDFS内部结构的直接修改。 - 检查配置和日志：仔细检查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.shDataNode已经正常启动
