从删库到跑路，NameNode元数据丢失如何恢复Hadoop集群

首先，回一下Hadoop的基础概念，从概念入手恢复集群。

HDFS metadata以树状结构存储整个HDFS上的文件和目录，以及相应的权限、配额和副本因子（replication factor）等。本文基于Hadoop2.6版本介绍HDFS Namenode本地目录的存储结构和Datanode数据块存储目录结构，也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.namenode.data.dir。

一、NameNode

HDFS metadata主要存储两种类型的文件

1、fsimage

记录某一永久性检查点（Checkpoint）时整个HDFS的元信息

2、edits

所有对HDFS的写操作都会记录在此文件中

 

Checkpoint介绍

HDFS会定期（dfs.namenode.checkpoint.period，默认3600秒）的对最近的fsimage和一批新edits文件进行Checkpoint（也可以手工命令方式），Checkpoint发生后会将前一次Checkpoint后的所有edits文件合并到新的fsimage中，HDFS会保存最近两次checkpoint的fsimage。Namenode启动时会把最新的fsimage加载到内存中。

接下来是重点。

1、VERSION

namespaceID=1242163293
clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9
cTime=1455091012961
storageType=NAME_NODE
blockpoolID=BP-180412957-40.32.10.18-1419305031110
layoutVersion=-60

• layoutVersion - HDFS metadata版本号，通常只有HDFS增加新特性时才会更新这个版本号
• namespaceID/clusterID/blockpoolID - 这三个ID在整个HDFS集群全局唯一，作用是引导Datanode加入同一个集群。在HDFS Federation机制下，会有多个Namenode，所以不同Namenode直接namespaceID是不同的，分别管理一组blockpoolID，但是整个集群中，clusterID是唯一的，每次format namenode会生成一个新的，也可以使用-clusterid手工指定ID
• storageType - 有两种取值NAME_NODE /JOURNAL_NODE，对于JournalNode的参数dfs.journalnode.edits.dir，其下的VERSION文件显示的是JOURNAL_NODE
• cTime - HDFS创建时间，在升级后会更新该值

2、edits_start transaction ID-end transaction ID

finalized edit log segments，在HA环境中，Standby Namenode只能读取finalized log segments，

3、edits_inprogress__start transaction ID

当前正在被追加的edit log，HDFS默认会为该文件提前申请1MB空间以提升性能

4、fsimage_end transaction ID

每次checkpoing（合并所有edits到一个fsimage的过程）产生的最终的fsimage，同时会生成一个.md5的文件用来对文件做完整性校验

5、seen_txid

保存最近一次fsimage或者edits_inprogress的transaction ID。需要注意的是，这并不是Namenode当前最新的transaction ID，该文件只有在checkpoing(merge of edits into a fsimage)或者edit log roll(finalization of current edits_inprogress and creation of a new one)时才会被更新。

这个文件的目的在于判断在Namenode启动过程中是否有丢失的edits，由于edits和fsimage可以配置在不同目录，如果edits目录被意外删除了，最近一次checkpoint后的所有edits也就丢失了，导致Namenode状态并不是最新的，为了防止这种情况发生，Namenode启动时会检查seen_txid，如果无法加载到最新的transactions，Namenode进程将不会完成启动以保护数据一致性。

6、in_use.lock

防止一台机器同时启动多个Namenode进程导致目录数据不一致

当集群CDH/AMBARI 的mysql元数据库(多为集群配置，hue,hive 授权信息，表结构等)被删除，NameNode和JourNalNode的fsimage和edits信息都被删除后，千万不要懵逼。下面是踩坑后的思路

1、看运维大佬能不能恢复磁盘。

2、查看NN和JN下面是不是还有没有删干净的，注意lost+found下面也是可以用的。

3、集群恢复启动。只启动NN和JN，DN不启动。

4、对比NN下的最新的edits信息是否在JN中存在。如果存在。把JN最新的edits和fsimage copy做备份。

5、修改namespace、clusterid、blockid 每台机器的每个副本需要一致，不同机器的肯定不同。clusterid集群每次格式化都会产生一个新的。都是一致的。这个是特例。。

6、启动新搭建的集群。静静等待建立新的索引。

7、索引块建立完，启动DN做block上报。数据量大的情况需要等时间长些。

8、集群基本恢复。当DN上报完block信息，索引建立完就可以恢复业务了。

以上为踩坑思路历程，如果有不明白的。可以私聊博主或者直接评论留言。