SecondaryNameNode的Inconsistent checkpoint fields异常

一、概念介绍

    hadoop.tmp.dir配置参数指定hdfs的默认临时路径,这个最好配置,如果在新增节点或者其他情况下莫名其妙的DataNode启动不了,就删除此文件中的tmp目录即可。不过如果删除了NameNode机器的此目录,那么就需要重新执行NameNode格式化的命令。

    此参数最好在安装时进行配置

<property>
    <name>hadoop.tmp.dir</name>
    <value>/data/hadoop/tmp</value>
</property>

二、hdfs的SecondaryNameNode的日志报Inconsistent checkpoint fields异常的原因

    最近在本机测试hadoop集群时,发现SecondaryNameNode的日志总是报Inconsistent checkpoint fields异常:ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Exception in doCheckpoint
java.io.IOException: Inconsistent checkpoint fields.
    

    此异常即是配置hadoop.tmp.dir参数引起的,在hdfs-site.xml中增加此参数,重新启动集群即可。

时间: 2024-10-29 06:41:46

SecondaryNameNode的Inconsistent checkpoint fields异常的相关文章

Hadoop Namenode不能启动 dfs/name is in an inconsistent

Hadoop Namenode不能启动 dfs/name is in an inconsistent 前段时间自己的本机上搭的Hadoop环境(按文档的伪分布式),第一天还一切正常,后来发现每次重新开机以后都不能正常启动, 在start-dfs.sh之后jps一下发现namenode不能正常启动,按提示找到logs目录下namenode的启动log发现如下异常 org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: D

Findbugs异常总汇

FindBugs是基于Bug Patterns概念,查找javabytecode(.class文件)中的潜在bug,主要检查bytecode中的bug patterns,如NullPoint空指针检查.没有合理关闭资源.字符串相同判断错(==,而不是equals)等 一.Security 关于代码安全性防护 1.Dm: Hardcoded constant database password (DMI_CONSTANT_DB_PASSWORD) 代码中创建DB的密码时采用了写死的密码. 2.Dm

NAMENODE工作机制,元数据管理(元数据存储机制、元数据手动查看)、元数据的checkpoint、元数据目录说明(来自学习资料)

NAMENODE工作机制 学习目标:理解namenode的工作机制尤其是元数据管理机制,以增强对HDFS工作原理的理解,及培养hadoop集群运营中"性能调优"."namenode"故障问题的分析解决能力   问题场景: 1.集群启动后,可以查看目录,但是上传文件时报错,打开web页面可看到namenode正处于safemode状态,怎么处理? 解释: safemode是namenode的一种状态(active/standby/safemode安全模式) namen

ORA-07445出现异常错误:核心转储 [ldxsnf()+625] [SIGSEGV

ALERT日志中报错信息: Mon Jan 20 15:03:22 2014 Incremental checkpoint up to RBA [0x442f.abd.0], current log tail at RBA [0x442f.338a.0] Mon Jan 20 15:08:13 2014 Errors in file /oracle/product/10.2.0/db/admin/PROD2_findbb/udump/prod2_ora_27268.trc: ORA-07445:

针对checkpoint的概要分析

checkpoint概要 什么是checkpoint 在数据库系统中,写日志和写数据文件是数据库中IO消耗最大的两种操作,在这两种操作中写数据文件属于分散写,写日志文件是顺序写,因此为了保证数据库的性能,通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中,而脏数据块着保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中.也就是说日志写入和提交操作是同步的,而数据写入和提交操作是不同步的.这样就存在一个问题,当一个数据库崩溃的时候并不能保证缓存里

Effective C#原则45:选择强异常来保护程序

当你抛出异常时,你就在应用程序中引入了一个中断事件.而且危机到程序 的控制流程.使得期望的行为不能发生.更糟糕的是,你还要把清理工作留给最 终写代码捕获了异常的程序员.而当一个异常发生时,如果你可以从你所管理的 程序状态中直接捕获,那么你还可以采取一些有效的方法.谢天谢地,C#社区不 须要创建自己的异常安全策略,C++社区里的人已经为我们完成了所有的艰巨的 工作.以Tom Cargill的文章开头:"异常处理:一种错误的安全感觉, " 而且Herb Sutter,Scott Meyer

Spring多线程注入时报null异常

在用多线程注入Spring的时候,注入的实例在调用时总是显示为null. 解决方案: 1.将实例传入线程,实例多的时候会死人的(⊙o⊙)- 2.[推荐]将多线程用到的实例进行全局化,即加static,这样就将实例提升到了进程的级别,两个线程都可以使用. 如下: protected static IDetailDataDao detailDataDao; @Autowired 或 @Resource(name = "detailDataDao") publicvoid setDetail

详解Android中处理崩溃异常_Android

大家都知道,现在安装Android系统的手机版本和设备千差万别,在模拟器上运行良好的程序安装到某款手机上说不定就出现崩溃的现象,开发者个人不可能购买所有设备逐个调试,所以在程序发布出去之后,如果出现了崩溃现象,开发者应该及时获取在该设备上导致崩溃的信息,这对于下一个版本的bug修复帮助极大,所以今天就来介绍一下如何在程序崩溃的情况下收集相关的设备参数信息和具体的异常信息,并发送这些信息到服务器供开发者分析和调试程序. 我们先建立一个crash项目,项目结构如图: 在MainActivity.ja

spark streaming 中使用saveAsNewAPIHadoopDataset方法写入hbase中,从checkpoint中恢复时报错

问题描述 最近写了一个从Kafka读取数据,处理之后通过saveAsNewAPIHadoopDataset方法写入到hbase中,正常运行的时候没有报错,写入也正常,但是当手动停止应用,再次执行(通过Checkpoint恢复)的时候就会报错,跪求大神们解答!!报错信息如下:15/12/2216:26:52WARNVerifiableProperties:Propertyserializer.classisnotvalid15/12/2216:26:57WARNFileOutputCommitte