情景再现: 在修复hadoop集群某一个datanode无法启动的问题时,搜到有一个答案说要删除hdfs-site.xml中dfs.data.dir属性所配置的目录,再重新单独启动该datanode即可: 问题就出在这个误删除上,当时是在namenode的hadoop/hdfs/目录下,然后就执行了一个可怕的命令 rm -rf data rm -rf name #存储namenode永久性元数据目录 当时还不知道删除这个的可怕,以为只是误删除了普通数据而已,然后再转到datanode下再次执行删…

前提:如果namenode没有做HA,那么至少应该启用secondarynamenode,以便namenode宕机之后手动恢复数据 实验环境:3个节点(cenos 6.10) 测试前数据: 1.为了确保数据尽可能恢复,手动checkpoint一下 [root@hadoop1 dfs]# hdfs secondarynamenode -checkpoint force /************************************************************ STA…

解决方法: 1.通过lsof -i:50070(lsof可以通过yum install lsof安装)查看,发现是mysql被占用了 2.修改mysql端口 从/usr/share/mysql/my-default.cnf复制成/etc/my.cnf文件:修改/etc/my.cnf文件,如下 如果,您认为阅读这篇博客让您有些收获,不妨点击一下右下角的[推荐]. 如果,您希望更容易地发现我的新博客,不妨点击一下左下角的[关注我]. 如果,您对我的博客所讲述的内容有兴趣,请继续关注我的后续博客,我是…

大家都知道在双十一这些电商大型营销活动期间,电商网站的访问量等是平时的N倍.每当这个时候到来,无论是开发还是运维人员都严阵以待生怕服务出现问题.很不幸,笔者的一个朋友在一家电商公司上班,在双十一时,恰恰就出现了NameNode宕机的生产事故. 鉴于涉及到一些公司私密信息,不便发一些排查问题截图,同时,JVM调优作为大数据从业者必备技能,笔者打算后续分篇系统阐述,这里仅就问题现象.问题分析.解决方案三个层面阐述这次生产事故从产生.排查到最终解决的历程.希望能给大家带来一定思考,避免此类事情的发生以…

一.dits和fsimage      首先要提到两个文件edits和fsimage,下面来说说他们是做什么的. 集群中的名称节点(NameNode)会把文件系统的变化以追加保存到日志文件edits中. 当名称节点(NameNode)启动时,会从镜像文件 fsimage 中读取HDFS的状态,并且把edits文件中记录的操作应用到fsimage,也就是合并到fsimage中去.合并后更新fsimage的HDFS状态,创建一个新的edits文件来记录文件系统的变化 那么问题来了,只有在名称节点(N…

.namenode 如何判断datanode节点是否宕机? 先决条件: datanode每隔一段时间像namenode汇报,汇报的信息有两点 ()自身datanode的状态信息: ()自身datanode所持有的所有的数据块的信息. 如果namenode连续十次没有收到datanode的汇报,那么namenode就会认为该datanode存在宕机的可能. datanode启动以后会专门启动一个进程负责给namenode发送心跳数据包,如果datanode没有问题,仅仅只是发送信息数据包的进程挂了…

今天遇到一起ORACLE数据库宕机案例,下面是对这起数据库宕机案例的原因进行分析.解读.分析过程中顺便记录一下这个案例的前因后果,攒点经验值,培养一下分析.解决问题的能力. 案例环境:   操作系统 :Oracle Linux Server release 5.7 64 bit 数据库版本:Oracle Database 10g Release 10.2.0.4.0 - 64bit Production 案例分析: 收到告警去检查数据库时,发现实例已经宕机.检查告警日志,发现下面错误信息: OR…

错误: FATAL org.apache.hadoop.hdfs.server.namenode.NameNode Exception in namenode join java.io.IOException There appears to be a gap in the edit log 原因: namenode元数据被破坏,需要修复 解决:     恢复一下namenode hadoop namenode –recover 一路选择c,一般就OK了 如果,您认为阅读这篇博客让您有些收获,不…

距离上个迭代过了很长时间,中间经历了很多事情,也在每个空余时间构思了这个迭代的东西以及下个迭代要做的东西.时间周期稍微长了,望见谅. 而且,至今这个开源库的start也已经到了165个了,会支持关注和研究的. 首先解决了上个迭代遇到的问题进行完善和修复: 1. 上个迭代做ajax timeout设置的时候,手抖将timeout不小心设置成timeoutEvent,这期做了修复 2. 解决全局配置中配置额外参数,批量检查时会参数错误问题. 引入新的功能: 1. 增加浏览器发送请求的错误监控和搜集…

最近某hadoop集群多次出现机器宕机,现象为瞬间机器的sys cpu增长至100%,机器无法登录.只能硬件重启,ganglia cpu信息如下: 首先怀疑有用户启动了比较奇葩的job,导致不合理的系统调用出现的问题.随后加了ps及pidstat信息收集job信息(公共集群蛋疼的地方),然后出现问题的时候,各类脚本已经无法工作, 一直没有抓到现场. 终于在某一次看到一台机器sys 瞬间增长,且机器还能登录.立马查看现场,发现竟然元凶是datanode:datanode一个进程占用cpu 1600…