hadoop 异常及处理总结 (小马哥-原创)

举报
北京小马哥 发表于 2018/12/31 08:42:36 2018/12/31
【摘要】 试验环境:  本地:MyEclipse  集群:Vmware 11+ 6台 Centos 6.5  Hadoop版本: 2.4.0(配置为自动HA)试验背景: 在正常测试MapReduce(下简称MR)程序4次之后,进行一次新的MR程序,MyEclipse的控制台信息卡住不动了,我通过远程连接NameNode查看系统目录也被卡住,这时候再看MyEclipse控制台,发现已经抛出异常如...

试验环境:

  本地:MyEclipse

  集群:Vmware 11+ 6台 Centos 6.5

  Hadoop版本: 2.4.0(配置为自动HA)

试验背景:

     在正常测试MapReduce(下简称MR)程序4次之后,进行一次新的MR程序,MyEclipse的控制台信息卡住不动了,我通过远程连接NameNode查看系统目录也被卡住,这时候再看MyEclipse控制台,发现已经抛出异常如下:

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException): Operation category READ is not supported in state standby

通过Web页面查看两个NameNode状态,均已经变成Standby,这让我很是奇怪,在自动故障恢复的集群配置下,竟然也会有全部变成备用的情况出现.

防止有人无常拷贝:加个作者链接:http://www.cnblogs.com/hadoop2015/

 

解决方法:

方法1:(结果不起作用)

我通过Shell命令方式,hadoop/bin/hdfs haadmin -failover --forceactive hadoop2 hadoop1(注意,这种方式本来是在手动故障恢复中进行强制切换NameNode的做法)

返回结果,不支持,并且诚恳的提示,这种方式是在手动故障转移的情况下,该命令才会起作用

方法2:(奏效)

我使用JPS检查了一下ZooKeeper集群的状态,发现没有任何征兆的失效了两个,原来是ZK的原因,于是重新启动ZK集群

然后重新启动ZKFailoverController(DFSZKFailoverController):没有这个角色存在,自然不会自动切换NameNode了

 

得到的教训,虽然NameNode通过HA机制,已经比Hadoop1可靠了,但是ZK集群一定要保证数量,我仅仅设置了三个节点的ZK集群,而ZK集群的可靠要保证:活动的ZK节点数量>(ZK节点总数-1)/2.所以,多多的设置ZK集群的节点才是王道.

联系本文作者交流或者索取相关代码及软件请加入QQ群:小马哥的技术分享 413939157.


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。