hadoop错误记录部分总结

错误记录与分析

错误1：java.net.BindException: Port in use: localhost:0

datanode节点启动时报错
日志信息如下：
Exiting with status : java.net.BindException: Port in use: localhost:
解决：在/etc/hosts文件开头添加如下内容
::    localhost
127.0.0.1    localhost

错误2：datanode节点磁盘空间爆满，导致datanode启动不能启动

解决:
、查看数据
hadoop fs -du -h /user/data/hadoop
、删除最旧的数据
hadoop fs -rm -r -skipTrash /user/hadoop/data/-* 删除一个月的
 
注：这里只是举一个样例，当空间不足的时候，就删掉某一数据。但是，通常情况下，在配置部署集群的时候，都会配置磁盘预留10%的容量。
 
还有一种情况：当某一块磁盘容量100%的时候，datanode节点不能启动。这种解决方法就是删除这块磁盘下的某些不重要的数据，比如日志文件。删除以后可以正常启动，接着执行balancer就可以。

错误3：java.io.IOException: Premature EOF from inputStream

报错信息如下：
 
-- ::, INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Exception for BP--x.x.x.x-:blk_1100079604_26351635
java.io.IOException: Premature EOF from inputStream
 
从错误来看，是由于文件被提前关闭，导致io错误。发生这种情况通常是在客户端读写hdfs上的文件时发生的。
 
解决：
1、修改hdfs-site.xml（每个节点都要改）：
   dfs.datanode.max.transfer.threads 值修改为8192。这个是datanode同时处理请求的任务上限，总默认值是 4096，该参数取值范围[1 to 8192]。
2、修改操作系统打开文件数。
当然也有可能是其他问题导致的。

错误4：org.apache.hadoop.net.ConnectTimeoutException: 60000 millis timeout while waiting for channel to be ready for connect

k_1087564514_13888513 received exception org.apache.hadoop.net.ConnectTimeoutException:  millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/58.240.56.125:]
// :: WARN balancer.Dispatcher: Failed to move blk_1087564434_13888433 with size= from x.x.x.x::DISK to y.y.y.y::DISK through x.x.x.x:: block move is failed: opReplaceBlock BP--x.x.x.x-:blk_1087564434_13888433 received exception org.apache.hadoop.net.ConnectTimeoutException:  millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/x.x.x.x:]
 
hadoop客户端连接超时问题
解决
修改hdfs-site.xml文件，添加
hdfs客户端的读写超时时间
dfs.client.socket-timeout(默认60000)
 
dfs.datanode.socket.write.timeout(默认80000)
 
dfs.datanode.handler.count=

错误5：All datanodes 58.240.56.122:50010 are bad. Aborting.

这个问题的原因不确定，可能会有多种情况导致。
1、查看当前系统的最大打开文件数量是否受限制；ulimt -n。
 
我这边系统的最大文件数量已经被设置为65535，但依然在hbase的日志里面大量的报这个错误。最后发现是由于datanode服务器压力过大导致，最后通过调整hbase的regionserver的heap大小降低服务器的压力。(一共两台datanode 0.0)
 
可能还要其他原因导致，这边暂时没有分析出来，期待以后补上了。

错误5：AttemptID:attempt_1547604600777_0101_r_000085_0 Timed out after 600 secs 或者 Too Many fetch failures.Failing the attempt

reduce任务失败，最终导致整个作业失败。
问题分析：这个是由于某个reduce任务重试4次后，job失败，原因就是因为超时。mapreduce.task.timeout参数对应的超时时间是600s。这意味着，如果map或reduce方法在600秒内没有返回或者输出内容，
NM将认为相应的map或reduce已经死亡。 并向AM汇报错误。AM会杀死此次尝试，并在其他节点上重新执行它。
可能导致的原因：
()、跑reduce任务的datanode节点压力大，可以使用top、iostart、sar等命令查看系统资源使用情况。也有可能datanode挂掉。
()、网络问题，网络IO过大。
()、程序死循环。
(4)、数据倾斜。
解决：
检查网络问题、datanode节点是否资源不足。

错误6：java.io.IOException: Broken pipe

原因分析
 
().当访问某个服务突然服务器挂了，就会产生Broken pipe;
 
().客户端读取超时关闭了连接，这时服务器往客户端再写数据就发生了broken pipe异常！

错误7：java.net.SocketTimeoutException: 60000 millis timeout while waiting for channel to be ready for read. ch

解决：打开core-site.xml文件
添加：ipc.ping.interval=

错误8：ssh连接问题：shell request failed on channel 0

分析：操作系统进程数量太小，导致连接失败
解决：修改操作系统最大进程数量
ulimit -u 查看最大进程数量。

错误9：The accepted epoch, d is less than the current epoch, 5e4

zookeeper启动报错
解决：进入到zookeeper数据目录下的version-2目录，把acceptedEpoch文件里面的值改成currentEpoch里面的值，也就是上述的5e4.

错误10：namenode报错，the directory item limit is exceed: limit=1048576

调整hadoop单个目录下的文件数量：
namenode日志里面可能存在如下错误：
the directory item limit is exceed: limit=
hadoop单个目录下文件超1048576个，默认limit限制数为1048576，所以要调大limit限制数
调整：
参数：dfs.namenode.fs-limits.max-directory-items
值：    注：值范围  ~ 
 
将配置文件推送至hadoop集群所有节点
重启hadoop服务

错误11：journalnode报错，org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited 96275 ms (timeout=20000 ms) for a response for sendEdits. No responses yet.

调节journalnode 的写入超时时间，默认20000(20s)
namenode日志文件可能存在的错误：
org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited  ms (timeout= ms) for a response for sendEdits. No responses yet.
参数：dfs.qjournal.write-txns.timeout.ms
值：(200s)

错误12：java.io.IOException: Can't scan a pre-transactional edit log.

由于数据磁盘爆满，达到100%，导致journalnode宕掉，在启动journalnode以后，查看日志，提示Can't scan a pre-transactional edit log，这个时候namenode已经是不能正常启动了。
 
java.io.IOException: Can't scan a pre-transactional edit log.
        at org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$LegacyReader.scanOp(FSEditLogOp.java:)
        at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanNextOp(EditLogFileInputStream.java:)
        at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanEditLog(EditLogFileInputStream.java:)
        at org.apache.hadoop.hdfs.server.namenode.FileJournalManager$EditLogFile.scanLog(FileJournalManager.java:)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.scanStorageForLatestEdits(Journal.java:)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:)
        at 
 
解决办法：
 
、删除数据磁盘的一些无用的数据，让磁盘有一定的空间，只要空间>0k,journalnode就可以正常启动，我这边就是某一块盘一点磁盘空间都没有，可用空间0k。导致在启动journalnode的时候提示磁盘空间不足，说到底，还是集群在规划的时候没有预留磁盘空间导致的，给差评。
 
、报上述的 Can't scan a pre-transactional edit log  错误，就是由于journalnode维护的eidts文件损坏，这个时候，看一下journalnode几台节点，哪一台是好的，先删除损坏的journalnode的数据文件，然后把这台好的journalnode文件拷贝到其他的节点。
 
、修改拷贝过来的数据文件的权限
 
、重启journalnode。

错误13：启动hadoop进程提示ssh 22端口不能连接

分析：由于在生产环境下，ssh的端口被修改成220，不是使用的默认端口，但是hadoop在启动相应进程的时候，使用的ssh默认端口
 
解决：
 
、命令行(临时)，这种方式会导致关闭当前终端，该值失效。
 
export HADOOP_SSH_OPTS="-p 220"
、永久修改：把上述的命令添加到hadoop的hadoop-env.sh文件，添加以后就可以正常启动hadoop进程。

错误14：Unable to fence NameNode at master/172.17.0.11:8020

解决：
提示未找到fuster程序，导致无法进行fence，所以可以通过如下命令来安装，Psmisc软件包中包含了fuster程序
#apt-get update
# apt-get install psmisc