hadoop错误记录部分总结

错误记录与分析

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

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

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

解决:
1、查看数据
hadoop fs -du -h /user/data/hadoop
2、删除最旧的数据
hadoop fs -rm -r -skipTrash /user/hadoop/data/2018-11* 删除一个月的

注：这里只是举一个样例，当空间不足的时候，就删掉某一数据。但是，通常情况下，在配置部署集群的时候，都会配置磁盘预留10%的容量。

还有一种情况：当某一块磁盘容量100%的时候，datanode节点不能启动。这种解决方法就是删除这块磁盘下的某些不重要的数据，比如日志文件。删除以后可以正常启动，接着执行balancer就可以。

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

报错信息如下：

2019-03-08 09:54:12,046 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Exception for BP-2086716179-x.x.x.x-1547613222606: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: 60000 millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/58.240.56.125:50010]
19/03/11 18:14:44 WARN balancer.Dispatcher: Failed to move blk_1087564434_13888433 with size=40766000 from x.x.x.x:50010:DISK to y.y.y.y:50010:DISK through x.x.x.x:50010: block move is failed: opReplaceBlock BP-1866268144-x.x.x.x-1464939869265:blk_1087564434_13888433 received exception org.apache.hadoop.net.ConnectTimeoutException: 60000 millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/x.x.x.x:50010]

hadoop客户端连接超时问题
解决
修改hdfs-site.xml文件，添加
hdfs客户端的读写超时时间
dfs.client.socket-timeout(默认60000)

dfs.datanode.socket.write.timeout(默认80000)

dfs.datanode.handler.count=50

错误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会杀死此次尝试，并在其他节点上重新执行它。
可能导致的原因：
(1)、跑reduce任务的datanode节点压力大，可以使用top、iostart、sar等命令查看系统资源使用情况。也有可能datanode挂掉。
(2)、网络问题，网络IO过大。
(3)、程序死循环。
(4)、数据倾斜。
解决：
检查网络问题、datanode节点是否资源不足。

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

原因分析

(1).当访问某个服务突然服务器挂了，就会产生Broken pipe;

(2).客户端读取超时关闭了连接，这时服务器往客户端再写数据就发生了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=180000

错误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=1048576
hadoop单个目录下文件超1048576个，默认limit限制数为1048576，所以要调大limit限制数
调整：
参数：dfs.namenode.fs-limits.max-directory-items
值：3200000    注：值范围 1 ~ 6400000

将配置文件推送至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 96275 ms (timeout=20000 ms) for a response for sendEdits. No responses yet.
参数：dfs.qjournal.write-txns.timeout.ms
值：200000(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:4974)
        at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanNextOp(EditLogFileInputStream.java:245)
        at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanEditLog(EditLogFileInputStream.java:355)
        at org.apache.hadoop.hdfs.server.namenode.FileJournalManager$EditLogFile.scanLog(FileJournalManager.java:551)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.scanStorageForLatestEdits(Journal.java:192)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:152)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:90)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:99)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:189)
        at 


解决办法：

1、删除数据磁盘的一些无用的数据，让磁盘有一定的空间，只要空间>0k,journalnode就可以正常启动，我这边就是某一块盘一点磁盘空间都没有，可用空间0k。导致在启动journalnode的时候提示磁盘空间不足，说到底，还是集群在规划的时候没有预留磁盘空间导致的，给差评。

2、报上述的 Can't scan a pre-transactional edit log  错误，就是由于journalnode维护的eidts文件损坏，这个时候，看一下journalnode几台节点，哪一台是好的，先删除损坏的journalnode的数据文件，然后把这台好的journalnode文件拷贝到其他的节点。

3、修改拷贝过来的数据文件的权限

4、重启journalnode。

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

分析：由于在生产环境下，ssh的端口被修改成220，不是使用的默认端口，但是hadoop在启动相应进程的时候，使用的ssh默认端口

解决：

1、命令行(临时)，这种方式会导致关闭当前终端，该值失效。

export HADOOP_SSH_OPTS="-p 220"
2、永久修改：把上述的命令添加到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