hadoop secondary namenode 部署出错所产生的错误及解决方法

只叙述secondary namenode部署出错所产生的错误及解决方法

环境:suse 10.1

namenode 单独部署在cloud1

secondary namenode 单独部署在 cloud3

集群部署完成后使用Jps查看进程,发现该有的进程都有,hdfs也能上传下载文件

 查看secondary name 上的log,发现在doCheckpoint都失败


2011-11-11 00:02:58,154 ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Exception in doCheckpoint:
2011-11-11 00:02:58,155 ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
        at java.net.Socket.connect(Socket.java:529)
        at java.net.Socket.connect(Socket.java:478)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:395)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:234)
        at sun.net.www.http.HttpClient.New(HttpClient.java:307)
        at sun.net.www.http.HttpClient.New(HttpClient.java:324)
发现secondary namenode不能产生image文件夹更别说image内的fimage,edits等文件
查看name node上的log 

2011-11-11 23:13:03,628 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Roll Edit Log from 10.0.1.162
2011-11-11 23:18:03,642 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Roll Edit Log from 10.0.1.162
没有错误,但是没有没有提示获取成功信息

关闭集群,在hdfs-site.xml中指定

<property>
	<name>dfs.http.address</name>
	<value>{your_namenode_ip}:50070</value>
</property>

分发到下去,重启,发现image文件夹内文件都有了,再次产看secondar namenode上的日志仍然doCheckPoint失败

查看namenode上的log

2011-11-17 13:31:57,434 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
        at java.net.Socket.connect(Socket.java:529)
        at java.net.Socket.connect(Socket.java:478)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:395)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:234)
        at sun.net.www.http.HttpClient.New(HttpClient.java:307)
        at sun.net.www.http.HttpClient.New(HttpClient.java:324)
        at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970)
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911)
        at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
可以得知secondary namenode上传image失败,所以namenode也就getimage失败了

查了下发现时由于没有指定secondary 的地址,因此很多人在测试的时候由于namenode和secondary namenode是在同一台机子上

而默认的dfs.secondary.http.adress值是0.0.0.0:50090,所以两者能进行通信。但是当分开部署的时候没有指定这个值而默认去在本机上取数据上传数据

当然就出错了。这个我想很多人在部署的时候都没有太注意

       <property>
                <name>dfs.secondary.http.address</name>
                <value>cloud3:50090</value>
        </property>
将上述参数指定好,重启下hadoop,再次查看secondary namenode上的log,log变成了

2011-11-17 14:20:31,435 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0
2011-11-17 14:20:31,443 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file fsimage size 6699 bytes.
2011-11-17 14:20:31,445 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file edits size 4 bytes.
2011-11-17 14:20:31,445 INFO org.apache.hadoop.hdfs.util.GSet: VM type       = 64-bit
2011-11-17 14:20:31,445 INFO org.apache.hadoop.hdfs.util.GSet: 2% max memory = 17.77875 MB
2011-11-17 14:20:31,445 INFO org.apache.hadoop.hdfs.util.GSet: capacity      = 2^21 = 2097152 entries
2011-11-17 14:20:31,445 INFO org.apache.hadoop.hdfs.util.GSet: recommended=2097152, actual=2097152
2011-11-17 14:20:31,447 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: fsOwner=ppstat
2011-11-17 14:20:31,447 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: supergroup=supergroup
2011-11-17 14:20:31,447 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: isPermissionEnabled=true
2011-11-17 14:20:31,447 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: dfs.block.invalidate.limit=100
2011-11-17 14:20:31,448 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: isAccessTokenEnabled=false accessKeyUpdateInterval=0 min(s), accessTokenLifetime=0 min(s)
2011-11-17 14:20:31,448 INFO org.apache.hadoop.hdfs.server.namenode.NameNode: Caching file names occuring more than 10 times
2011-11-17 14:20:31,448 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files = 53
2011-11-17 14:20:31,460 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files under construction = 7
2011-11-17 14:20:31,463 INFO org.apache.hadoop.hdfs.server.common.Storage: Edits file /data/cloud/hadoop/tmp/dfs/namesecondary/current/edits of size 4 edits # 0 loaded in 0 seconds.
2011-11-17 14:20:31,464 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0
2011-11-17 14:20:31,470 INFO org.apache.hadoop.hdfs.server.common.Storage: Image file of size 6699 saved in 0 seconds.
2011-11-17 14:20:31,477 INFO org.apache.hadoop.hdfs.server.common.Storage: Image file of size 6699 saved in 0 seconds.
2011-11-17 14:20:31,480 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Posted URL cloud1:50070putimage=1&port=50090&machine=cloud3&token=-31:114395553:0:1321510831000:1321510231897
2011-11-17 14:20:31,491 WARN org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Checkpoint done. New Image Size: 6699
说明我们获取image,并上传成功到namenode成功了

在查看namenode

2011-11-17 14:20:31,972 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Roll FSImage from 10.0.1.162
2011-11-17 14:20:31,972 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 1 SyncTimes(ms): 1 
2011-11-17 14:30:31,997 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Roll Edit Log from 10.0.1.162
2011-11-17 14:30:31,997 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0 

说明就是由于没有指定secondary namenode地址所造成的。


ppstat@cloud3:/data/cloud/hadoop/tmp/dfs/namesecondary/current> ll
总计 20
-rw-r--r-- 1 ppstat users    4 2011-11-17 14:40 edits
-rw-r--r-- 1 ppstat users 6699 2011-11-17 14:40 fsimage
-rw-r--r-- 1 ppstat users    8 2011-11-17 14:40 fstime
-rw-r--r-- 1 ppstat users  100 2011-11-17 14:40 VERSION


PS:抱怨下,csdn的blog越弄越垃圾了,编辑起来一点都不方便,坑爹的玩意


  • 4
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
### 回答1: Secondary NamenodeHadoop 集群中的一个重要组件,主要负责协助 NameNode 完成一些工作,如备份和合并 fsimage 和 editlog 文件。 Secondary Namenode 能够有效的缩短 Hadoop 集群的启动时间,主要是因为: 1. 辅助 NameNode 的启动:当 NameNode 启动的时候,需要将内存中的数据持久化到磁盘,这个过程比较耗时,而 Secondary Namenode 可以在 NameNode 启动之前,帮助将内存数据写入到磁盘,从而加快 NameNode 的启动时间。 2. 减少 Namenode 的工作量:NameNode 负责管理整个 Hadoop 集群的元数据,随着集群规模的增大,元数据的大小也会不断增加,导致 NameNode 的工作量变得越来越大。而 Secondary Namenode 可以定期的从 NameNode 中备份元数据,并且合并 fsimage 和 editlog 文件,从而减轻了 NameNode 的工作压力。 综上所述,Secondary NamenodeHadoop 集群中具有非常重要的作用,能够有效的缩短 Hadoop 集群的启动时间,同时减轻 NameNode 的工作压力,提高集群的稳定性。 ### 回答2: secondary namenodehadoop中辅助namenode的一个节点,负责周期性地将namenode的数据合并成一个新的镜像,并将该镜像发送给namenode,以便在namenode故障时帮助它重新启动。secondary namenode并不是集群中的核心节点,但它的作用却十分重要。使用secondary namenode可以大大缩短hadoop集群的启动时间,具体原因如下: 1.帮助主节点恢复快速 主节点(namenode)存储了整个HDFS文件系统的元数据,因此如果主节点故障,整个HDFS文件系统将无法使用。但是,如果有secondary namenode存在,secondary namenode会持续地从主节点中拷贝namenode的状态,并会在主节点故障时对其进行恢复。这样就可以更快地使整个HDFS文件系统恢复正常,从而有效缩短了集群的启动时间。 2.辅助namenode工作 namenode是整个HDFS系统的核心,如果它在启动时遇到了问题,那么整个HDFS文件系统会受到影响。但是,如果有secondary namenode存在,它可以辅助namenode工作,从而处理更多数据,使namenode在重建HDFS文件系统时,更加高效地完成工作。 综上所述,secondary namenode作为集群中的一个辅助节点,它的存在可以帮助主节点故障快速恢复,同时辅助namenode高效地完成文件系统重建,因此可以有效缩短hadoop集群的启动时间,提高HDFS的可靠性和效率。 ### 回答3: Secondary NameNodeHadoop集群中的一个重要组件,它可以有效缩短Hadoop集群的启动时间。 通常情况下,Hadoop集群的NameNode节点存储大量的元数据信息,以确保Hadoop集群的正常运行。但是,随着数据量的增加和时间的推移,NameNode的元数据信息也会不断增加,这会导致Hadoop集群的启动时间慢慢变长。 为了解决这一问题,Hadoop引入了Secondary NameNode作为辅助节点来协助NameNode执行一些任务,例如合并fsimage和edits文件、监控HDFS集群的健康状态等。通过运用Secondary NameNode,可以将NameNode的负载分散到多个节点上,从而大大提高了Hadoop集群的启动速度和稳定性。 具体来说,Secondary NameNode通常会执行两种任务。一是定期从NameNode中获取元数据信息,并将其合并成一个镜像文件fsimage,这个文件可以保留与NameNode相同的元数据信息,从而可以恢复出错的NameNode。二是定期将NameNode的edits日志中积累的命名空间的变更应用到fsimage文件,以确保fsimage文件的信息与实际情况相符合。 由此可见,Secondary NameNode是非常重要的一个组件,它能够缩短Hadoop集群的启动时间,提高Hadoop集群的稳定性和可靠性。同时,我们也可以采取一些措施,例如增加节点数量、优化节点配置等,来进一步提高Hadoop集群的性能和效率。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值