hadoop 常见问题整理

ntp时间服务同步

第一种方式：同步到网络时间服务器

 # ntpdate time.windows.com
将硬件时间设置为当前系统时间。 
#hwclock –w 
加入crontab：    
30 8 * * * root /usr/sbin/ntpdate 192.168.0.1; /sbin/hwclock -w 每天的8:30将进行一次时间同步。
重启crond服务：
service crond restart

第二种方式：同步到局域网内部的一台时间同步服务器
一、搭建时间同步服务器
1、编译安装ntp server
rpm -qa | grep ntp
若没有找到，则说明没有安装ntp包，从光盘上找到ntp包，使用
rpm -Uvh ntp***.rpm
进行安装
2、修改ntp.conf配置文件
vi /etc/ntp.conf
①、第一种配置：允许任何IP的客户机都可以进行时间同步
将“restrict default nomodify notrap noquery”这行修改成：
restrict default nomodify notrap
配置文件示例：/etc/ntp.conf
②、第二种配置：只允许192.168.211.***网段的客户机进行时间同步
在restrict default nomodify notrap noquery（表示默认拒绝所有IP的时间同步）之后增加一行：
restrict 192.168.211.0 mask 255.255.255.0 nomodify notrap
3、启动ntp服务
service ntpd start
开机启动服务
chkconfig ntpd on
4、ntpd启动后，客户机要等几分钟再与其进行时间同步，否则会提示“no server suitable for synchronization found”错误。

二、配置时间同步客户机
手工执行 ntpdate 来同步
或者利用crontab来执行
crontab -e
0 21 * * * ntpdate 192.168.211.22 >> /root/ntpdate.log 2>&1
每天晚上9点进行同步
附：
当用ntpdate -d 来查询时会发现导致 no server suitable for synchronization found 的错误的信息有以下2个：
错误1.Server dropped: Strata too high
在ntp客户端运行ntpdate serverIP，出现no server suitable for synchronization found的错误。
在ntp客户端用ntpdate –d serverIP查看，发现有“Server dropped: strata too high”的错误，并且显示“stratum 16”。而正常情况下stratum这个值得范围是“0~15”。
这是因为NTP server还没有和其自身或者它的server同步上。
以下的定义是让NTP Server和其自身保持同步，如果在/ntp.conf中定义的server都不可用时，将使用local时间作为ntp服务提供给ntp客户端。
server 127.127.1.0
fudge 127.127.1.0 stratum 8

在ntp server上重新启动ntp服务后，ntp server自身或者与其server的同步的需要一个时间段，这个过程可能是5分钟，在这个时间之内在客户端运行ntpdate命令时会产生no server suitable for synchronization found的错误。
那么如何知道何时ntp server完成了和自身同步的过程呢？
在ntp server上使用命令：
# watch ntpq -p
出现画面：
Every 2.0s: ntpq -p                                                                                                             Thu Jul 10 02:28:32 2008
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
192.168.30.22   LOCAL(0)         8 u   22   64    1    2.113 179133.   0.001
LOCAL(0)        LOCAL(0)        10 l   21   64    1    0.000   0.000  0.001
注意LOCAL的这个就是与自身同步的ntp server。
注意reach这个值，在启动ntp server服务后，这个值就从0开始不断增加，当增加到17的时候，从0到17是5次的变更，每一次是poll的值的秒数，是64秒*5=320秒的时间。
如果之后从ntp客户端同步ntp server还失败的话，用ntpdate –d来查询详细错误信息，再做判断。
错误2.Server dropped: no data
从客户端执行netdate –d时有错误信息如下：
transmit(192.168.30.22) transmit(192.168.30.22)
transmit(192.168.30.22)
transmit(192.168.30.22)
transmit(192.168.30.22)
192.168.30.22: Server dropped: no data
server 192.168.30.22, port 123
.....
28 Jul 17:42:24 ntpdate[14148]: no server suitable for synchronization found出现这个问题的原因可能有2：
1。检查ntp的版本，如果你使用的是ntp4.2（包括4.2）之后的版本，在restrict的定义中使用了notrust的话，会导致以上错误。
使用以下命令检查ntp的版本：
# ntpq -c version
下面是来自ntp官方网站的说明：
The behavior of notrust changed between versions 4.1 and 4.2.
In 4.1 (and earlier) notrust meant "Don't trust this host/subnet for time".
In 4.2 (and later) notrust means "Ignore all NTP packets that are not cryptographically authenticated." This forces remote time servers to authenticate themselves to your (client) ntpd
解决：
把notrust去掉。
2。检查ntp server的防火墙。可能是server的防火墙屏蔽了upd 123端口。
可以用命令
#service iptables stop

来关掉iptables服务后再尝试从ntp客户端的同步，如果成功，证明是防火墙的问题，需要更改iptables的设置。

namenode安全模式问题

当namenode发现集群中的block丢失数量达到一个阀值时，namenode就进入安全模式状态，不再接受客户端的数据更新请求

在正常情况下，namenode也有可能进入安全模式：
    集群启动时（namenode启动时）必定会进入安全模式，然后过一段时间会自动退出安全模式（原因是datanode汇报的过程有一段持续时间）
    
也确实有异常情况下导致的安全模式
    原因：block确实有缺失
    措施：可以手动让namenode退出安全模式，bin/hdfs dfsadmin -safemode leave
          或者：调整safemode门限值：  dfs.safemode.threshold.pct=0.999f
    

HDFS冗余数据块的自动删除

在日常维护hadoop集群的过程中发现这样一种情况：
    某个节点由于网络故障或者DataNode进程死亡，被NameNode判定为死亡，HDFS马上自动开始数据块的容错拷贝；当该节点重新添加到集群中时，由于该节点上的数据其实并没有损坏，所以造成了HDFS上某些block的备份数超过了设定的备份数。通过观察发现，这些多余的数据块经过很长的一段时间才会被完全删除掉，那么这个时间取决于什么呢？
    该时间的长短跟数据块报告的间隔时间有关。Datanode会定期将当前该结点上所有的BLOCK信息报告给Namenode，参数dfs.blockreport.intervalMsec就是控制这个报告间隔的参数。
    hdfs-site.xml文件中有一个参数：

    dfs.blockreport.intervalMsec
    3600000
    Determines block reporting interval in milliseconds.

    其中3600000为默认设置，3600000毫秒，即1个小时，也就是说，块报告的时间间隔为1个小时，所以经过了很长时间这些多余的块才被删除掉。通过实际测试发现，当把该参数调整的稍小一点的时候（60秒），多余的数据块确实很快就被删除了。

hadoop安装部署问题总结

1、hadoop启动不正常
用浏览器访问namenode的50070端口，不正常，需要诊断问题出在哪里：
a、在服务器的终端命令行使用jps查看相关进程
（namenode1个节点   datanode3个节点   secondary namenode1个节点）
b、如果已经知道了启动失败的服务进程，进入到相关进程的日志目录下，查看日志，分析异常的原因
1）配置文件出错，saxparser  exception； ——找到错误提示中所指出的配置文件检查修改即可
2）unknown host——主机名不认识，配置/etc/hosts文件即可，或者是配置文件中所用主机名跟实际不一致
   （注：在配置文件中，统一使用主机名，而不要用ip地址）
3）directory 访问异常—— 检查namenode的工作目录，看权限是否正常

start-dfs.sh启动后，发现有datanode启动不正常
a）查看datanode的日志，看是否有异常，如果没有异常，手动将datanode启动起来
sbin/hadoop-daemon.sh start datanode
b）很有可能是slaves文件中就没有列出需要启动的datanode
c）排除上述两种情况后，基本上，能在日志中看到异常信息：
   1、配置文件
   2、ssh免密登陆没有配置好
   3、datanode的身份标识跟namenode的集群身份标识不一致（删掉datanode的工作目录）

 

datanode节点超时时间设置

datanode进程死亡或者网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout，则超时时长的计算公式为：
    timeout  = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
    而默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。
    需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。所以，举个例子，如果heartbeat.recheck.interval设置为5000（毫秒），dfs.heartbeat.interval设置为3（秒，默认），则总的超时时间为40秒。
    hdfs-site.xml中的参数设置格式：

        heartbeat.recheck.interval
        2000


        dfs.heartbeat.interval
        1