datanode节点启动时报错

日志信息如下：

Exiting with status : java.net.BindException: Port in use: localhost:

解决：在/etc/hosts文件开头添加如下内容

::    localhost

127.0.0.1    localhost

解决:

、查看数据

hadoop fs -du -h /user/data/hadoop

、删除最旧的数据

hadoop fs -rm -r -skipTrash /user/hadoop/data/-* 删除一个月的

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

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

报错信息如下：

-- ::, 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、修改操作系统打开文件数。
当然也有可能是其他问题导致的。

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=

这个问题的原因不确定，可能会有多种情况导致。
1、查看当前系统的最大打开文件数量是否受限制；ulimt -n。

我这边系统的最大文件数量已经被设置为65535，但依然在hbase的日志里面大量的报这个错误。最后发现是由于datanode服务器压力过大导致，最后通过调整hbase的regionserver的heap大小降低服务器的压力。(一共两台datanode 0.0)

可能还要其他原因导致，这边暂时没有分析出来，期待以后补上了。

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节点是否资源不足。

原因分析

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

().客户端读取超时关闭了连接，这时服务器往客户端再写数据就发生了broken pipe异常！

解决：打开core-site.xml文件

添加：ipc.ping.interval=

分析：操作系统进程数量太小，导致连接失败

解决：修改操作系统最大进程数量
ulimit -u 查看最大进程数量。

zookeeper启动报错

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

调整hadoop单个目录下的文件数量：

namenode日志里面可能存在如下错误：

the directory item limit is exceed: limit=

hadoop单个目录下文件超1048576个，默认limit限制数为1048576，所以要调大limit限制数

调整：

参数：dfs.namenode.fs-limits.max-directory-items

值：    注：值范围  ~ 

将配置文件推送至hadoop集群所有节点

重启hadoop服务

调节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)

由于数据磁盘爆满，达到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。

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

解决：

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

export HADOOP_SSH_OPTS="-p 220"

、永久修改：把上述的命令添加到hadoop的hadoop-env.sh文件，添加以后就可以正常启动hadoop进程。

解决：

提示未找到fuster程序，导致无法进行fence，所以可以通过如下命令来安装，Psmisc软件包中包含了fuster程序

#apt-get update

# apt-get install psmisc