WSL环境Hadoop上传文件报0 datanodes及重启数据丢失问题

• 宿主机操作系统：Windows 10
• 子系统环境：基于WSL运行Ubuntu 20.04.3 LTS，内核版本为GNU/Linux 4.4.0-19041-Microsoft x86_64

• 执行start-all.sh脚本启动Hadoop集群后，通过jps命令查询运行进程，DataNode进程缺失
• 执行本地文件上传至HDFS操作时，抛出错误：0 datanodes available
• HDFS文件下载至本地目录的操作可正常完成，通过ls -l命令可在本地目录查看到已下载的文件
• 集群运行期间可正常在HDFS内创建目录、写入文件，但重启Ubuntu终端后，此前创建的所有目录、文件全部丢失，HDFS存储为空

# 启动Hadoop集群
start-all.sh
# 查询进程，返回结果中无DataNode进程
jps
# 执行本地文件上传HDFS操作，报错0 datanodes available
hdfs dfs -put <local_file_path> <hdfs_target_path>
# 执行HDFS文件下载到本地操作，可正常完成
hdfs dfs -get <hdfs_file_path> <local_target_path>

1. DataNode进程缺失的核心原因通常是重复执行hdfs namenode -format，导致NameNode与DataNode的clusterID不匹配，DataNode身份校验失败后主动退出
2. WSL默认将/tmp目录挂载为临时存储，Hadoop默认临时数据目录为/tmp/hadoop-${user.name}，WSL实例重启时会自动清空/tmp目录下的所有内容，造成HDFS元数据、存储块全部丢失
3. WSL1未完整实现POSIX文件系统标准接口，部分版本下DataNode依赖的文件锁机制无法正常运行，会导致DataNode启动后立即崩溃

1. 停止所有运行中的Hadoop进程：

   stop-all.sh
   

2. 调整Hadoop数据存储路径，规避WSL临时目录自动清空问题：
   • 在非/tmp路径下创建专用的Hadoop数据存储目录，例如~/hadoop/tmp、~/hadoop/namenode、~/hadoop/datanode，为目录授予读写权限
   • 编辑Hadoop配置文件etc/hadoop/core-site.xml，将hadoop.tmp.dir配置项的值修改为新建的tmp目录绝对路径
   • 编辑etc/hadoop/hdfs-site.xml，添加或修改dfs.namenode.name.dir、dfs.datanode.data.dir配置项，值分别对应新建的namenode、datanode目录绝对路径
3. 修复clusterID不匹配问题：
   • 清空上述新建的三个数据目录下的所有残留文件
   • 执行一次hdfs namenode -format完成NameNode格式化，注意集群初始化完成后，后续重启不需要重复执行格式化操作
4. 若使用WSL1仍存在DataNode启动失败问题，直接将WSL升级为WSL2版本，WSL2搭载完整原生Linux内核，无POSIX接口兼容性问题
5. 重新执行start-all.sh启动集群，通过jps确认DataNode进程正常运行后，依次验证文件上传、下载、重启后数据持久化功能即可

内容的提问来源于stack exchange，提问作者pmk