namenode 启动失败

启动hdfs后(start-dfs.sh), 发现jps中namenode的进程不存在,导致hdfs连接不成功。

查看log,发现其中:

2015-03-11 20:23:00,986 FATAL org.apache.hadoop.hdfs.server.namenode.NameNode: Exception in namenode join
org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: Directory /tmp/hadoop-root/dfs/name is in an inconsistent state: storage directory does not exist or is not accessible.
        at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverStorageDirs(FSImage.java:311)
        at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:202)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:955)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:700)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:529)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:585)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:751)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:735)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1407)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1473)
2015-03-11 20:23:00,988 INFO org.apache.hadoop.util.ExitUtil: Exiting with status 1
2015-03-11 20:23:00,989 INFO org.apache.hadoop.hdfs.server.namenode.NameNode: SHUTDOWN_MSG:

检查后发现hadoop配置文件 etc/hadoop/core-site.xml 中有一处配置 hadoop.tmp.dir, 原先配置在了/tmp/目录下。

由于Ubuntu会自动清理该目录,机器重启后该目录被清空,导致该问题。

解决方法是:

修改该配置文件:

<property>

   <name>hadoop.tmp.dir</name>

   <value>/hdfs/name</value>

   <description>A base for other temporary directories.</description>

</property>

并且重新fomat hdfs,重新启动hdfs后问题解决:

[email protected]:~# jps
11076 NameNode
11304 DataNode
11593 SecondaryNameNode
11722 Jps

时间: 2024-08-12 17:46:27

namenode 启动失败的相关文章

hadoop namenode启动失败

hadoop version=3.1.2 生产环境中,一台namenode节点突然挂掉了,,重新启动失败,日志如下: Info=-64%3A1391355681%3A1545175191847%3ACID-9160c87b-3ab7-4372-98a1-536a59dd36ef&inProgressOk=true' to transaction ID 159168296 2019-03-05 14:38:06,460 INFO org.apache.hadoop.hdfs.server.name

[原创]Hadoop默认设置导致NameNode启动失败一例

看到市面上很多书在讲解Hadoop的时候都轻描淡写的提到了HDFS的设置问题.大多采取的是默认设置,最多也就是设置一些副本数量之类. 笔者在工作中遇到了这样一种情况:每次重启系统之后,NameNode就会消失. 重新尝试下面的命令: hdfs namenode –format sbin/start-all.sh 这样确实能够恢复Hadoop的运行,但是HDFS上面的数据会全部丢失.这显然不是我们想看到的. 仔细查找官方文档,发现hdfs-site.xml里面包含了HDFS的默认工作路径,竟然指向

hadoop namenode启动异常,死活失败

2014-05-12注定是春光灿烂猪八戒的一天,历史595无故障的hadoop服务器,终于还是出了问题,事前无人登陆操作服务器,此故障属于自发行为,目前未知发生原因. 细节描述: namenode无法启动. 先贴出错误信息 2014-05-12 07:17:39,447 INFO org.apache.hadoop.hdfs.server.namenode.NameNode: STARTUP_MSG: /**********************************************

hadoop启动后,jps命令后发现nodename启动失败,检查日志报错:FSNamesystem initialization failed

1. 基本信息 hadoop    版本 hadoop-0.20.205.0.tar.gz 操作系统   ubuntu 2. 问题 在使用Hadoop开发初期的时候遇到一个问题. 每次重启系统后发现不能正常运行hadoop.必须执行  bin/hadoop namenode -format  进行格式化才能成功运行hadoop,但是也就意味着以前记录的name等数据丢失. 查询日志发现错误: 21:08:48,103 INFO org.apache.hadoop.hdfs.server.name

记一次Alluxio HA master启动失败

1. 今天遇到一个情况,就是alluxio不能正常访问,经过日志查看,发现下面错误. 2018-05-14 03:35:58,680 ERROR logger.type (HdfsUnderFileSystem.java:open) - 4 try to open hdfs://sandy-bridge/user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001 : Cannot obtain block le

Mongodb分片配置服务器不同步导致mongos进程启动失败

生产环境中,使用的mongodb分片,由于突然断电,服务再起来的时候发现三个mongos进程中有一个启动失败,多次尝试仍不能启动.查看日志,内容如下: 大概意思是配置服务器configserver数据不同步. 解决办法: 杀死所有mongos进程 连接到每个分片的configserver,运行命令db.runCommand('dbhash') 找到MD5值,这时两个能正常运行的MD5值是一样的,不能正常运行的MD5和上面俩都不一样 删除不能正常运行的dbpath,将能正常运行的dbpath下的数

多学一点(十三)——解决Linux kdump服务启动失败

kdump 是 Linux Kernel 崩溃时的转储机制,简单理解就是在系统启动过程中如果 Kernel 因为某些原因崩溃了,kdump 就会负责记录日志以便排查原因.在 CentOS 6 等 Linux 发行版中,即便采用最小化安装, kdump 也会作为服务安装到系统中,此时可能因为我们对 Linux分配的内存的限制导致 kdump 服务开机启动失败,如图 1 所示: 图-1 kdump启动失败 解决 kdump 启动失败其实很简单,只要修改 grub.conf 文件,改变crashker

ORA-01078和LRM-00109问题导致ORACLE启动失败解决方法

操作环境 SuSE11 + ORACLE11gR2(11.2.0.3) 问题现象 新安装ORACLE启动失败,提示ORA-01078和LRM-00109错误.具体错误现象如下 SQL> startup ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/home/oracle/base/dbs/initora11g.ora'  问题分析 根据错误分析是查找不到参

CentOs 6.6里kdump启动失败的原因

在VMware中新安装了CentOs 6.6,重启系统发现kdump服务启动失败 先来说一下,什么是kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制.当系统崩溃时,kdump 使用 kexec 启动 到第二个内核.第二个内核通常叫做捕获内核,以很小内存启动以捕获转储镜像.第一个内核保 留了内存的一部分给第二内核启动用.由于 kdump 利用 kexec 启动捕获内核,绕过了 BIOS,所 以第一个内核的内存得以保留.这是内核崩溃转储的本质. 启动失败的原因 查看 /etc