1.简介
造成环境异常的问题和恢复可通过以下几种情况:
1. 日志文件积累造成没有磁盘空间节点进入安全模式
2. 节点进入进入黑名单
3. Edits文件过大造成没有磁盘空间
4. 服务器关闭
5. Oozie调度工作流恢复方法
2.日志文件积累造成没有磁盘空间
2.1hadoop日志文件
Hadoop的日志文件存储在/var/log/hadoop-0.20下,只需清除历史日志文件,再使用命令:hadoop dfsadmin -safemode leave 再使用重启节点命令即可恢复。
2.2Oozie日志文件
Oozie的日志文件存储在/export/data/mysql/logs下,只需清除历史日志文件,再使用命令:hadoopdfsadmin -safemode leave 再使用重启节点命令即可恢复。
2.3设置Linux定时命令自动清理
目前测试环境已添加Linux的定时命令,自动完成清理日志功能。脚本在/root下的rmHadoopLog.sh文件。
文件内容: rm -rf /var/log/hadoop-0.20/history/*
执行频率:1天一次
3. 节点进入黑名单
测试环境经常会有节点进入黑名单,造成该问题有一下几种情况
3.1无法写入日志造成进入黑名单
此时磁盘空间仍有空余,但某个文件夹下存在的日志文件数目过多,造成系统运行缓慢,不能在规定的时间内写入日志文件,造成hadoop的master节点与计算节点间通信时间增长,到达一定程度后将该节点写入黑名单。清除无用的日志文件,再重启节点即可解决该问题。
3.2计算失败数过多进入黑名单
HadoopMachine List页面将显示各计算节点的运行情况,当Task Failures数目积累到一定程度后,该节点也会被写入黑名单。重启节点即可解决。
3.3虚拟机间通信时间过长造成进入黑名单
如果虚拟机服务器不在同一网段,会造成通信时间增长,当到达一定程度后将该节点写入黑名单,该问题属于通信问题,只能让运维解决。
4.Edits文件过大造成没有磁盘空间
问题:存在一个edits文件和一个备份文件各占用超大的空间。造成namenode节点进入安全模式。
解决方法:该edits文件存储的为所有hdfs的input、output及缓存文件,不可以在Linux下直接清除该文件,需要使用hadoop fs –rmr 命令清理没用的input和output目录。目前系统加入了secondary namenode来及时备份和清理edits。
相关资料:fsimage是存于硬盘的元数据检查点,Hadoop不会对每个文件操作都写出到fsimage,这样是很慢的,但是每个文件操作都会在提交后运行前先写入edits编辑日志,这样在namenode出现故障后,就会将fsimage和edits编辑日志结合读入内存,重建元数据信息,一旦清理了edits,即造成无法恢复。
为了避免edits编辑日志的无限制扩大,secondary namenode 就回按照时间阈值(比如1小时)或者按大小阈值(edits编辑日志文件大小超过64M,这些参数都可以设置)“周期性”的读取namenode中的edits和fsimage重构fsimage检查点,同时在namenode中进行edits的滚动,来解决这个问题。
5.服务器关闭
测试环境的机器存在多个网段,一个网段为一台实机,当发现无法连接到虚机,请通知运维来解决。
6. Oozie调度工作流恢复方法
当以上几种情况出现后,会造成大范围的工作流报错不能继续运行等问题。请采用以下方法快速回复
1. 进入到oozie数据库,select * from coord_actions将所有status=’SUSPENDED’的数据delete掉。到达调度运行时间后即可生成新的工作流。
2. 进入hdfs,清除个别fail或kill掉后不能自动删除的lock锁。
经过以上两个步骤,大部分工作流都可继续正常运行,但这两个步骤操作起来,比较复杂,任何的失误将造成调度彻底瘫痪。
3. 解决个别工作流:
(1) 如果调度不能继续生成工作流,查看是否仍有SUSPENDED或FAIl的调度影响造成的无法继续生成,或调度死掉,需要kill掉重新挂工作流。
(2) 如果调度生成工作流计算失败,请根据报错信息处理。
(3) 需要重新挂调度的话,请根据具体的工作流处理响应的历史文件和数据。