Hadoop开发过程中所遇到的那些坑_hadoop怎么删除tmp目录

---

核心内容：
1、Hadoop开发过程中常见问题即解决方案

---

在Hadoop开发的过程中，我们总是遇到各种各样的问题，今天就整理总结一下：

在Hadoop开发的过程中如果遇到各种异常，首先使用jps命令查看节点的启动是否正常，然后在去查看相关的日志文件，但是在查看相关日志之前，你可以先检查一下面几点： 1、防火墙原因：检查各个节点的防火墙是否关闭成功。（重点是检查NameNode）

[root@hadoop11 ~]# service iptables status
iptables: Firewall is not running.
2、检查IP地址与主机名的映射关系是否绑定成功

[root@hadoop11 ~]# more /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
10.187.84.50  hadoop11
10.187.84.51  hadoop22
10.187.84.52  hadoop33
10.187.84.53  hadoop44
10.187.84.54  hadoop55
10.187.84.55  hadoop66
1
2
3
4
5
6
7
8

3、检查NameNode是否处于安全模式

[root@hadoop11 ~]# hadoop dfsadmin -safemode get
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.

Safe mode is OFF
1
2
3
4
5

4、检查NameNode是否已经进行了格式化处理

<property>
    <name>hadoop.tmp.dir</name>
    <value>/usr/local/hadoop/tmp</value>
</property>
1
2
3
4

5、检查配置文件的配置是否成功
6、检查NameNode节点和DataNode节点中存放的namespaceID的版本号是否相同

[root@hadoop11 current]# pwd
/usr/local/hadoop/tmp/dfs/name/current
[root@hadoop11 current]# more VERSION 
#Wed Nov 02 21:27:01 CST 2016
namespaceID=1890187682
clusterID=CID-6a82f5f4-a705-4a20-bfda-ee5e9a69c3de
cTime=0
storageType=NAME_NODE
blockpoolID=BP-574118934-10.187.84.50-1478093221696
layoutVersion=-56


[root@hadoop44 current]# pwd  
/usr/local/hadoop/tmp/dfs/data/current/BP-574118934-10.187.84.50-1478093221696/current
[root@hadoop44 current]# more VERSION 
#Sun Nov 27 09:37:03 CST 2016
namespaceID=1890187682
cTime=0
blockpoolID=BP-574118934-10.187.84.50-1478093221696
layoutVersion=-55
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

好的，当我们查看完上述6点之后如果还没有解决问题，那我们再去查看相关的日志文件即可。

OK，到现在为止我在给大家介绍一下在开发过程中经常遇到的几个异常问题：

这个问题对于Hadoop的初学者是经常遇到的，之所以出现这个问题，可能有3点原因：

1、NameNode没有进行格式化处理（6个检查以包括）
先删除hadoop.tmp.dir所对应的目录（即logs和tmp），然后对NameNode进行格式化处理

hadoop.tmp.dir
/usr/local/hadoop/tmp

2、检查IP地址与主机名的映射关系是否绑定成功（6个检查以包括）
3、检查配置文件的配置是否成功（6个检查以包括），重点是hadoop-env.sh、core-site.xml、hdfs-site.xml、mapred-site.xml和slaves。

例如：

原因：NameNode在刚开始启动的时候会进入到安全模式，倒计时30s后退出，在安全模式下会不能进行增、删、改操作，只能进行查看操作。但是如果数据节点DataNode丢失的block块达到一定比例的话则系统一直处于安全模式，即只读状态。
解决方法：
1、在HDFS的配置文件hdfs-site.xml中，修改dfs.safemode.threshold.pct所对应的数值，将其数值改成一个较小的数值，默认的数值是0.999f。

<property>
  <name>dfs.safemode.threshold.pct</name>
  <value>0.999f</value>
  <description>
    Specifies the percentage of blocks that should satisfy 
    the minimal replication requirement defined by dfs.replication.min.
    Values less than or equal to 0 mean not to wait for any particular
    percentage of blocks before exiting safemode.
    Values greater than 1 will make safe mode permanent.
  </description>
 </property>
1
2
3
4
5
6
7
8
9
10
11

2、执行命令 hadoop dfsadmin -safemode leave 强制NameNode离开安全模式。（6个检查以包括）

[root@hadoop11 hadoop]# hadoop dfsadmin -safemode leave
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.

Safe mode is OFF
1
2
3
4
5

例如：

这个异常可能出现的现象：执行命令jps显示的进程都很正常，但是用web界面查看的话，显示的live nodes为0，这说明数据节点DataNode没有正常启动，但是数据节点DataNode又正常启动了。
这个问题可能出现的原因：
1、防火墙原因，检查所有节点的防火墙是否关闭成功。（6个检查以包括）
2、磁盘空间原因：执行命令df -al 查看磁盘空间的使用情况，如果是磁盘空间不足的话，则调整磁盘空间。

如果是磁盘空间不足的话，具体进行下面的步骤在进行查看：

[root@hadoop66 local]# cd /
[root@hadoop66 /]# ls
bin   dev  home  lib64       media  mnt  opt   root  selinux  sys  usr
boot  etc  lib   lost+found  misc   net  proc  sbin  srv      tmp  var
[root@hadoop66 /]# du -sh *   （这个命令很重要）
7.6M    bin
27M     boot
264K    dev
36M     etc
5.4G    home
142M    lib
26M     lib64
16K     lost+found
4.0K    media
0       misc
4.0K    mnt
0       net
8.0K    opt
du: cannot access `proc/14788/task/14788/fd/4': No such file or directory
du: cannot access `proc/14788/task/14788/fdinfo/4': No such file or directory
du: cannot access `proc/14788/fd/4': No such file or directory
du: cannot access `proc/14788/fdinfo/4': No such file or directory
0       proc
2.6G    root
15M     sbin
0       selinux
4.0K    srv
0       sys
252K    tmp
31G     usr
256M    var
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

3、如果上述方法都不行的话，可用以下方法进行处理（但是该方法会造成数据的丢失，所以慎用！）
先删除hadoop.tmp.dir所对应的目录，然后对NameNode重新进行格式化处理。（6个检查以包括）

原因：集群中的主机名没有映射到相应的IP地址（6个检查以包括）
解决方法：在/etc/hosts文件中添加所有节点的主机名与IP地址的映射关系。

[root@hadoop11 ~]# more /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
10.187.84.50  hadoop11
10.187.84.51  hadoop22
10.187.84.52  hadoop33
10.187.84.53  hadoop44
10.187.84.54  hadoop55
10.187.84.55  hadoop66
1
2
3
4
5
6
7
8

解决方法：先删除hadoop.tmp.dir所对应的文件夹，然后对NameNode重新进行格式化处理。

<property>
  <name>hadoop.tmp.dir</name>
  <value>/tmp/hadoop-${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>
1
2
3
4
5

原因分析：出现这个异常，明显是JVM内存不足的原因，要修改所有数据节点DataNode所对应的JVM内存大小。
方法：在MapReduce的配置文件mapred-site.xml中，修改mapred.child.java.opts所对应的数值。

<property>
  <name>mapred.child.java.opts</name>
  <value>-Xmx200m</value>
</property>
1
2
3
4

注意：一般JVM的最大内存使用应该为总内存大小的一半，例如我们的服务器的内存大小为4G，则设置为2048m，但是这个值可能依旧不是最优的数值。其中
-Xms 表示内存初始化的大小，-Xmx表示能够使用的最大内存。
在linux 下查看服务器内存的硬件信息：

[root@hadoop11 ~]# cat /proc/meminfo |grep MemTotal
MemTotal:        3871080 kB
1
2

原因分析：每次对NameNode格式化之后都会产生一个新的namespaceID，如果多次对NameNode格式化的话可能导致NameNode节点和DataNode节点中存放的版本号不一致。
解决方法：
1、在NameNode节点和DataNode节点中检查namespaceID的版本号是否相同，如果不相同的话，修改为相同的值后然后重新启动该节点。（6个检查以包括）
2、先删除hadoop.tmp.dir所对应的目录，然后对NameNode重新进行格式化处理。（6个检查以包括）
上面这些就是我在开发过程中经常遇到的一些问题，希望对大家有所帮助。