HDFS2.0 NameNode HA 切换失败后的恢复(元数据写坏)

在测试 HDFS2.0 的 NameNode HA 的时候,并发put 700M的文件,然后 Kill 主 NN ;发现备 NN 切换后进程退出。

2014-09-03 11:34:27,221 FATAL org.apache.hadoop.hdfs.server.namenode.FSEditLog: Error: recoverUnfinalizedSegments failed for required journal (JournalAndStream(mgr=QJM to [10.136.149.96:8485, 10.136.149.97:8485, 10.136.149.99:8485], stream=null))
org.apache.hadoop.hdfs.qjournal.client.QuorumException: Got too many exceptions to achieve quorum size 2/3. 1 successful responses:
10.136.149.99:8485: null [success]
2 exceptions thrown:
10.136.149.97:8485: org/apache/hadoop/io/MD5Hash

然后重启 NN 两个 NN均失败 ,

怀疑是 JN 那里有问题,可能有垃圾产生,bin/hdfs namenode -initializeSharedEdits 启动NN ,还是失败

同步两个NN的 current 元数据目录 , 重启所有 JN, 然后启动 仍然失败 ;

怀疑是 NN 对元数据的合并出了问题, 删除报错开始 的 edits 文件 ,修改 seen_txid 中的 txid 编号;

启动 NN 成功,主备NN 均启动成功。

具体原因还在定位中,但至少环境已经恢复了,最近的edits 被遗弃了。

时间: 2024-08-25 17:27:08

HDFS2.0 NameNode HA 切换失败后的恢复(元数据写坏)的相关文章

Hadoop 2.0 NameNode HA和Federation实践

参考链接:Hadoop 2.0 NameNode HA和Federation实践 Posted on 2012/12/10 一.背景 天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案,由于行业的特殊性,客户对服务的可用性有着非常高的要求,而HDFS长久以来都被单点故障的问题所困扰,直到Apache Hadoop在2012年5月发布了2.0的alpha版本,其中MRv2还很不成熟,可HDFS的新功能已经基本可用,尤其是其中的的High Ava

namenode ha切换优化

一.背景 目前namenode使用了ha的部署模式,但系统会经常出现ha的自动切换(namenode节点其实正常).经过调研发现可能的原因如下: HealthMonitor check本地namenode的rpc端口时超时,导致HealthMonitor认为namenode挂掉. zk上的session timeout,导致丢掉当前持有的active锁(temp节点),引起自动切换. 二.优化 下面的优化将针对1)和2)调整相应的超时参数,看是否起效.修改core-site.xml     <!

Hadoop 2.6.0 Namenode HA,ResourceManager HA

先启动所有的zookeeper zkServer.sh start 在所有节点上启动JournalNode: sbin/hadoop-daemon.sh start journalnode 格式化第一个NameNode bin/hdfs namenode –format 启动第一个的NameNode sbin/hadoop-daemon.sh start namenode 在第二个NameNode上同步元数据 bin/hdfs namenode -bootstrapStandby 启动第二个Na

kafka 0.10.2 部署失败后,重新部署

删除kafka各个节点log目录 删除zookeeper上kafka相关的目录 [[email protected] ~]# zkCli.sh Connecting to localhost:2181 2017-03-22 07:06:47,239 [myid:] - INFO [main:[email protected]100] - Client environment:zookeeper.version=3.4.9-1757313, built on 08/23/2016 06:50 GM

iPhone更新失败后如何恢复数据

iPhone5最好不要用wifi下更新ios8.1,因为该固件比较大,很容易中途出问题失败,如果失败也不要怕,想要恢复数据还是有希望的. 如果不幸进入恢复模式,还没有实现备份,千万别点恢复,那就啥都没了!请往下看. (1)下载pp助手,尝试进入正常模式,如果可以,那就没问题了.如果无线进入恢复模式,好吧,往下看吧 (2)如果现在系统不是最新的系统,那就很轻松了,在pp助手的固件下载下载币现有系统新的固件. (3)然后进入itunes,会有更新和恢复两个选项,按住shift,然后点更新会打开文件件

Hadoop2.0构成之HDFS2.0

HDFS2.0之HA 主备NameNode: 1.主NameNode对外提供服务,备NameNode同步主NameNode元数据,以待切换: 2.主NameNode的信息发生变化后,会将信息写到共享数据存储系统中让备NameNode合并到自己的内存中: 3.所有DataNode同时向两个NameNode发送心跳信息(块信息): 两种切换方式: 1.手动切换:通过命令实现主备之间的切换,可以用于HDFS升级等场合: 2.自动切换:基于Zookeeper实现: Zookeeper Failover

【甘道夫】Hadoop2.2.0 NN HA详细配置+Client透明性试验【完整版】

引言: 前面转载过一篇团队兄弟[伊利丹]写的NN HA实验记录,我也基于他的环境实验了NN HA对于Client的透明性. 本篇文章记录的是亲自配置NN HA的详细全过程,以及全面测试HA对客户端访问透明性的全过程,希望对大家有帮助. 实验环境: Hadoop2.2.0的4节点集群,ZK节点3个(ZK节点数最好为奇数个),hosts文件和各节点角色分配如下: hosts: 192.168.66.91 master 192.168.66.92 slave1 192.168.66.93 slave2

Namenode HA原理详解

社区hadoop2.2.0 release版本开始支持NameNode的HA,本文将详细描述NameNode HA内部的设计与实现. 原文见 http://xiguada.org/namenode-ha-principle/ 为什么要Namenode HA? 1.NameNode High Availability即高可用. 2.NameNode 很重要,挂掉会导致存储停止服务,无法进行数据的读写,基于此NameNode的计算(MR,Hive等)也无法完成. Namenode HA 如何实现,关

Ubuntu 14.10 下ZooKeeper+Hadoop2.6.0+HBase1.0.0 的HA机群高可用配置

1 硬件环境 Ubuntu 14.10 64位 2 软件环境 openjdk-7-jdk hadoop 2.6.0 zookeeper-3.4.6 hbase-1.0.0 3 机群规划 3.1 zookeeper配置-机器结点 192.168.1.100 1421-0000192.168.1.106 1421-0003192.168.1.107 1421-0004192.168.1.108 1421-0005192.168.1.109 1421-0006 3.2 hadoop配置-机器结点 19