HDFS 中文件操作的错误集锦

Posted 2021-01-10 zhao-teng-ass

问题1  Java ApI执行追加写入时：无法写入
问题描述： ①当前数据节点无法写入，②追加文件需要再次请求。

 

问题2  命令行执行追加写入时：无法写入
问题描述： 当前数据节点无法写入

 

 

 

 

 

 

问题3  Java ApI上传时.crc校验文件的校检失败
问题描述： Java ApI上传文件时对原文件进行检验，导致无法正常上传

 

 

问题4   多次使用hadoop namenode  -format 格式化导致数据节点无法正常启动
问题描述：  使用hadoop namenode  -format 格式化时多次格式化造成了spaceID不一致	Jps命令没有datanode

 

三、解决方案：（列出遇到的问题和解决办法，列出没有解决的问题）：

问题1/2  Java ApI或命令行执行追加写入时：无法写入
问题原因	我的环境中有3个datanode，备份数量设置的是3。在写操作时，它会在pipeline中写3个机器。默认replace-datanode-on-failure.policy是DEFAULT,如果系统中的datanode大于等于3，它会找另外一个datanode来拷贝。目前机器只有3台，因此只要一台datanode出问题，就一直无法写入成功。
问题解决： （针对JAVA API）	在所要执行的代码中添加两句：       conf.set("dfs.client.block.write.replace-datanode-on-failure.policy","NEVER"); conf.set("dfs.client.block.write.replace-datanode-on-failure.enable","true");  一次执行，可能无响应，再次请求即可。 详细内容可参考以下教程解释：https://blog.csdn.net/caiandyong/article/details/44730031?utm_source=copy
问题解决： （针对命令行）	修改hdfs-site.xml文件，添加或者修改如下两项：     <property>         <name>dfs.client.block.write.replace-datanode-on-failure.enable</name>         <value>true</value>     </property>         <property>     <name>dfs.client.block.write.replace-datanode-on-failure.policy</name>         <value>NEVER</value>     </property>
注解	对于dfs.client.block.write.replace-datanode-on-failure.enable，客户端在写失败的时候，是否使用更换策略，默认是true没有问题 对于，dfs.client.block.write.replace-datanode-on-failure.policy，default在3个或以上备份的时候，是会尝试更换结点尝试写入datanode。而在两个备份的时候，不更换datanode，直接开始写。对于3个datanode的集群，只要一个节点没响应写入就会出问题，所以可以关掉。   详解参考：https://blog.csdn.net/themanofcoding/article/details/79512754?utm_source=copy

 

 

问题3 Java ApI上传时.crc校验文件的校检失败
问题原因	Hadoop客户端将本地文件text.txt上传到hdfs上时，hadoop会通过fs.FSInputChecker判断需要上传的文件是否存在.crc校验文件。如果存在.crc校验文件，则会进行校验。如果校验失败，自然不会上传该文件。 可能因为之前对原文件有更改，所以会对校检文件的校验进行干扰。
问题解决：	cd到文件所在路径，ls -a查看，果然存在.text.crc文件 $ ls -a 问题就很简单了，删除.crc文件 $ rm .text.crc 再上传即可。如下图所示。     详细内容可参考以下教程解释：https://blog.csdn.net/bitcarmanlee/article/details/50969025?utm_source=copy
注解	crc文件来源 DFS命令：hadoop fs -getmerge srcDir destFile 这类命令在执行的时候，会将srcDir目录下的所有文件合并成一个文件，保存在destFile中，同时会在本地磁盘生成一个. destFile.crc的校验文件。 DFS命令：hadoop fs -get -crc src dest 这类命令在执行的时候，会将src文件，保存在dest中，同时会在本地磁盘生成一个. dest.crc的校验文件。 如何避免 在使用hadoop fs -getmerge srcDir destFile命令时，本地磁盘一定会（没有参数可以关闭）生成相应的.crc文件。 所以如果需要修改getmerge获取的文件的内容，再次上传到DFS时，可以采取以下2种策略进行规避： 1. 删除.crc文件 2. 将getmerge获取的文件修改后重新命名，如使用mv操作，再次上传到DFS中。 更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

 

 

问题4   多次使用hadoop namenode  -format 格式化导致数据节点无法正常启动
问题原因	在第一次格式化dfs后，启动并使用了hadoop，后来又重新执行了格式化命令（hdfs namenode -format)，这时namenode的clusterID会重新生成，而datanode的clusterID 保持不变。
问题解决：  使用hadoop namenode  -format 格式化时多次格式化造成了spaceID不一致	1、停止集群（切换到/sbin目录下） $./stop-all.sh 2、删除在hdfs中配置的data目录（即在core-site.xml中配置的hadoop.tmp.dir对应文件件）下面的所有数据; $ rm -rf /home/hadoop/hdpdata/* 3、重新格式化namenode(切换到hadoop目录下的bin目录下) $ ./hadoop namenode -format 4、重新启动hadoop集群（切换到hadoop目录下的sbin目录下） $./start-all.sh 在使用hadoop dfsadmin -report查看使用情况，结果如下图所示： ok没有错误了。再次上传文件，成功。 转载：http://blog.csdn.net/weiyongle1996/article/details/74094989 详见：https://blog.csdn.net/love666666shen/article/details/74350358