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。
分析：由于在生产环境下，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
记录学习和生活的酸甜苦辣.....哈哈哈
