HDFS 中文件操作的错误集锦

问题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

转载于:https://www.cnblogs.com/zhao-teng-ass/p/9744675.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值